Planning Poker

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

Portfolio Backlog Refinement

Refinement of the Portfolio Backlog is the process of adding details to backlog entries, making estimates, splitting backlog entries, or changing the order of entries in the Portfolio Backlog. Refinement is a continuous process in which the Portfolio Owner and the Cluster System Engineer Group (CSEG) jointly detail the Portfolio Backlog entries. The entries are examined and revised as the Portfolio Backlog is refined. However, the Portfolio Owner can update or have the entries in the Portfolio Backlog updated at any time.

The Portfolio Backlog refinement is mainly used to prepare the next Portfolio Planning . The Portfolio Owner of the Cluster System Engineer Group (CSEG) presents new backlog entries and has them estimated. This is a prerequisite for the “pull” of the CSEG and is often referred to as definition-of-ready . In the case of unclear but highly prioritized backlog entries, the CSEG clarifies the System Requirements , possible System Concepts and capabilities . This can be worked out as a group or a corresponding backlog entry can be created as an order for one of the Clusters.

Estimation of the effort required to implement backlog entries

Estimates by the entire Cluster System Engineer Group are important for two reasons:

  1. By jointly estimating, the CSEG analyzes the respective backlog entry from different perspectives and enriches it with information such as acceptance criteria and boundary conditions. The first ideas for implementation are also generated.
  2. The result of the estimation is a number with which individual backlog elements can be evaluated, for example for prioritization. In addition, it is now easy to calculate how many backlog elements can be dragged into a cycle, namely by comparing the backlog elements completed in the last cycles ( organization velocity ).

The team uses the Planning-Poker ® methodology to estimate the effort .


Further suitable links:\r\n


Further suitable links:

Events Roles Groups Artifacts
Team Backlog Refinement .

Cluster Backlog Refinement

.

Portfolio Planning

Organization Sync

Portfolio Review

Organization retrospective

Portfolio Owner

Portfolio Architect

Organization Scrum Master

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organization Management Circle

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organization DoD

Organization Improvement Backlog

 

Team Backlog Refinement

The Team Backlog Refinement is the process of adding details to the Team Backlog entries, making estimates, and determining the order of the Team Backlog entries. Refinement is a continuous process in which the Team Product Owner and the Working Team together detail the Team Backlog entries. When the Team Backlog is refined, the entries are examined and revised. It should normally not take up more than 10% of the Working Team’s capacity. However, the Team Product Owner can update or have the entries in the Team Backlog updated at any time.

The Team Backlog Refinement mainly serves to prepare the next Team Planning . In this case, the Team Product Owner the Working Team new team Backlog Items before and can appreciate this from the Working Team. If entries are about to begin, the team makes sure that the entries are small enough that they can be dragged into an iteration. (This is a prerequisite for the “pull” and is often also referred to as part of the Definition of Ready (DoR) ). If this is not the case, the team refines the corresponding entry by splitting it into several entries (splitting).

If the team does not work in iterations, but continuously using Kanban, the team agrees on an estimate limit from which it is necessary to split Backlog Items.

Estimation of the implementation effort of backlog entries

Estimates by the entire team are important for two reasons

  1. By estimating together, the entire team analyzes the respective backlog entry from different perspectives and enriches it with information such as acceptance criteria and boundary conditions. The first ideas for implementation are also generated.
  2. The result of the estimate is a number with which individual backlog elements can be evaluated, for example for prioritization. In addition, it is now easy to calculate how many elements can be dragged into an iteration, namely by comparing the backlog elements completed in the last iterations (team velocity ).

The team uses the Planning-Poker ® method to estimate the effort .

\r\n


Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Sync

Team Review

Team Retrospective

.

Cluster Backlog Refinement

.

Portfolio Refinement

Team Product Owner

Team System Engineer

Team Scrum Master

Working Team

Community of Practice

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog