Category: Pragmatic Practices

Velocity

Oliver Schönfeld

Velocity is a measure of done Backlog Items delivered per Timebox (Iteration or Cycle). It is used to provide a forecast of future done work. Conditions are that the team and the timebox are stable over time.

Calculating Velocity

It is possible to calculate the Velocity of a Team for a single Iteration or Cycle. For better results we sum ip all “done” work of all timeboxes, measured in Story Points  (SP), and divide them by the number of timeboxes. This results in the mean Velocity over time.

 

Application of Velocity

  • Working Teams use it to calculate how much work to pull into the Iteration Backlog within Iteration Planning meetings. For better results it is typically normalized by non-regular absences like holidays and planned absences.
  • Product Owners use it to predict milestones and release dates of products.

. 

\r\n

Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

.

Cluster Planning

Cluster Sync

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

.

Portfolio Planning

Organisation Sync

Portfolio Refinement

Portfolio Review

Organisation Retrospective

 Team Product Owner

Team System Engineer

Team Scrum Master

.

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

.

Portfolio Owner

Portfolio Architect

Organisation Scrum Master

 Working Team

Community of Practice

.

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

.

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

 Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

.

Cluster Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

.

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organisation DoD

Organisation Improvement Backlog

Planning Poker

Oliver Schönfeld

What is Planning Poker?

Planning Poker is used for the group-based estimation of sizes, usually the effort or complexity in development projects. This is exactly how the value (business value) of features or products can be estimated.

But why “group-based”?

  • It avoids one-sided views (swarm intelligence).
  • It promotes structured discussions in groups.
  • Everyone in the group gets a better understanding about the discussed topic.

The anchor phenomenom makes it difficult to get real, individual assessments in group-based discussions. The anchor problem means, that the assessments by all discussion participants are subconsciously biased to the assessment of the first one, who initially explains his opinion (anchor). To avoid this effect, everybody has to make his individual decission secretly before sharing it with the other group members. This is exactly what planning poker cards are for.

Why relative?

There are also several reasons for this:

  • Humans are better at comparative/relative estimating than estimating absolute sizes
  • Real estimates are calibrated by comparing historical values. The effort actually required to implement a Backlog Item with 1 point is not known at the beginning, but can be determined after the Backlog Item has been finished. Usually not individual values are of interesting, but sums of values. Summing up values compensates errors.

And how does it work?

Just follow these simple and clear steps to successfully play Delegation Poker. It is best to stick strictly to it at the beginning and only change things if you really understand the system.

  1. Each team member gets a deck of estimation cards.
  2. The Product Owner explains the PBI (Product Backlog Item) and it is discussed briefly.
  3. Each team member selects a card, that is his estimate.
  4. All cards are turned over at once, so everybody can see them.
  5. Differences are discussed (especially outliers).
  6. Repeat estimating until estimates converge.

Reference

Planning poker needs at least one reference to be able to make relative estimates. Before the first estimate, it must be determined what corresponds to a 1. When estimating effort, many teams use the definition that 1 Story Point (SP) corresponds to an effort of half a person’s day (1SP = 1/2PD).

 

\r\n

Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Backlog Refinement

.

Cluster Planning

Cluster Backlog Refinement

.

Portfolio Planning

Portfolio Refinement

 

 Team Product Owner

.

Cluster Product Owner

.

Portfolio Owner

 Working Team

.

Team System Engineer Group

.

 

Cluster System Engineer Group

 Team Backlog

.

Cluster Backlog

.

Portfolio Backlog

Upswing Gravity Field

Oliver Schönfeld

The Upswing Gravity Field is a wonderful visualization for feature prioritization of Product and Portfolio Backlogs. The upswing describes the added value of a product or a function, the gravity describes the effort that the organization has to spend to achieve this. The priority corresponds to the quotient of value and effort (priority = value / effort). By using logarithmic quantities, such as in the Fibonacci sequence, a double logarithmic representation and a rotation of 45 degrees, we get these perfectly parallel priority lines.

Typically, Product Owners can best estimate the added value or the market value of different products against each other, but have less expertise in estimating the effort to implement. It is exactly the opposite with the Working Teams: They have the best understanding of implementation costs from all those involved in product development, but cannot estimate the market value as well. Therefore, in the P4 framework, added value and effort are estimated separately and shown in the upswing gravity field. It is a powerful tool for the product owner to assess priorities.

 

\r\n

Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Backlog Refinement

.

Cluster Planning

Cluster Backlog Refinement

.

Portfolio Planning

Portfolio Refinement

 

 Team Product Owner

.

Cluster Product Owner

.

Portfolio Owner

 Working Team

.

Team System Engineer Group

.

 

Cluster System Engineer Group

 Team Backlog

.

Cluster Backlog

.

Portfolio Backlog