10 APPROVE, ESTIMATE AND COMMIT USER STORIES
The User Stories, which are input to this process, have high-level estimates from the Create Prioritized Product Backlog and Create User Stories processes. These estimates are used by the Product Owner to approve User Stories for the Sprint.
It must be noted that it is the Product Owner's responsibility to ensure that approved User Stories deliver value and meet the needs and requirements of the Project Stakeholders. Once approved, the User Stories are estimated by the Team using the various estimation techniques discussed in this section. After estimation, the Team commits to a subset of approved and estimated User Stories that they believe they can complete in the next Sprint. These User Stories are Approved, Estimated, and Committed User Stories that will become part of the Sprint Backlog.
Although the Product Owner approves the initial User Stories for a Sprint, the final decision about which specific User Stories (among those approved by the Product Owner) should be chosen for the Sprint lies with the Scrum Team. The Scrum Team (with consultation from the Product Owner, if required) finalizes which User Stories they will be working on during the Sprint.
Planning Poker, also called Estimation Poker, is an estimation technique that uses consensus to estimate relative sizes of User Stories or the effort required to create them.
In Planning Poker, each Team member is assigned a deck of cards. Each card is numbered in a sequence and the numbers represent the complexity of the problem, in terms of time or effort, as estimated by the Team member. The Product Owner chooses a User Story from the Prioritized Product Backlog and presents it to the Team. The Scrum Team members assess the User Story and try to understand it better before providing their estimate for developing it.
Then, each member picks a card from the deck that represents his or her estimate for the User Story. If the majority or all Team members select the same card then the estimate indicated by that card will be the estimate for that User Story. If there is no consensus, then the Team members discuss reasons for selecting different cards or estimates. After this discussion, they pick cards again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached.
Planning Poker advocates greater interaction and enhanced communication among the participants. It facilitates independent thinking by participants, thus avoiding the phenomenon of groupthink.
Figure: Fibonacci Series Cards for Planning Poker
- Agile Planning Poker cards can be used for the activity, or simple numbers are written on paper prior to the meeting and distributed to Scrum Team members.
- Sizing and estimation using Planning Poker is an abstract method that takes the focus off the actual time in hours or days and instead puts the focus on describing the relative expense and complexity of a Task as compared to other Tasks.
The Scrum Team use Fibonacci-like numbers to estimate effort: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100:
- Number estimates are based on relative sizing that the Team feels is appropriate.
- Zero "0" means no effort required to complete this Story (functionality might get created due to completion of some other User Story); 1 means the Story is trivial; 5 means it’s average; 20 means it’s extremely difficult or much remains unknown.
- If the Team provides an estimate of 3 or 5 or 8 then those User Stories are perfect for this Team.
- 13 means the Team is asking nicely for you to break the Story down into smaller pieces if possible.
- 20 or 40 means the Team is telling you that Story is too big and it must be broken down into multiple smaller stories.
The Planning Poker process is conducted as follows:
- The Scrum Master allows the Team to read the Story, and, if necessary, the Product Owner or Functionality Expert explains the Story.
- The Scrum Master facilitates the discussion on dependencies, and what technical stories or technical Tasks need to be accomplished to support the Story completion. The technical stories or Tasks are noted.
- For User Stories or derived technical stories, the Scrum Master asks the developers to vote using Planning Poker method, with a "one-two-three-go!".
- The Scrum Master then challenges the highest and lowest votes to explain their position and rationale behind their selection, i.e. why they believe it is more or less difficult than their peers expect.
- The Scrum Master repeats the votes until the numbers converge and the Team as whole can agree on a number or small group of numbers.
- If the Team has not agreed on a single number then the Scrum Master decides the best number based on the number of votes, or sometimes by affording more weight to the votes of Team members who are most likely be working on that particular User Story.
- The Scrum Master assigns the effort points to the Story, a.k.a the Plan Estimate.
- Repeat until there are no more Stories or the allocated time for the meeting is exhausted.
The Fist of Five is a simple and fast mechanism to achieve consensus in a group and drive discussion. After initial discussion on a given proposal or a pending decision, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers. The value in using this technique is not only consensus building, but also driving discussion because each Team member is asked to explain the reason for their ranking. They are also given the opportunity to express any issues or concerns. Once the Team has discussed it, a collective decision will be made.
The number of fingers used to vote indicates the level of agreement and desire for discussion:
Fingers shown |
Meaning |
One finger: |
I disagree with the group's conclusion and have major concerns. |
Two fingers: |
I disagree with the group's conclusion and would like to discuss some minor issues. |
Three fingers: |
I am not sure and would like to go with the group's consensus conclusion. |
Four fingers: |
I agree with the group's conclusion and would like to discuss some minor issues |
Five fingers: |
I wholeheartedly agree with the group's conclusion. |
The Fist of Five method is also useful in certain cases to find out if people understand the discussion subject or the requirement in detail.
Figure: I do not understand at all; I need to go over this again; I think I get it, but am not completely comfortable; I got it; I can explain it to someone else.
10.3 Points for Cost Estimation
Cost estimation can be accomplished using relative units (e.g., effort estimates) rather than absolute units (i.e., actual costs incurred). In order to estimate the cost to implement a User Story, the Scrum Team can use Story Points. When this is done, the Cost Estimated for each Task will be in the form of Story Points, rather than monetary units. In order to do this successfully, the Scrum Team should identify a baseline User Story that all Team members can relate to. Once this baseline is identified, all Cost Estimates for User Stories should be done compared to that baseline. These estimates remain fixed throughout a Sprint because Teams are not supposed to change during a Sprint.
Wideband Delphi is a group-based estimation technique for determining how much work is involved and how long it will take to complete. Individuals within a Team anonymously provide estimations for each feature and the initial estimates are plotted on a chart. The Team then discusses the factors that influenced their estimates and proceed to a second round of estimation. This process is repeated until the estimates of individuals are close to each other and a consensus for the final estimate can be reached.
10.5 Relative Sizing and Story Points
In addition to being used for estimating cost, Story Points can also be used for estimating the overall size of a User Story or feature. This approach assigns a Story Point value based on an overall assessment of the size of a User Story with consideration given to risk, amount of effort required, and level of complexity. The Scrum Team will conduct this assessment and a Story Point value will be assigned. Once an evaluation is done on one User Story in the Prioritized Product Backlog, the Scrum Team can then evaluate other User Stories relative to that first Story. For example, a feature with a 2-point Story value must be twice as difficult to complete as a feature with a 1-point Story; a 3-point Story should be three times as difficult to complete as a 1-point Story.
Affinity Estimation is a technique used to quickly estimate a large number of User Stories. Using sticky notes or index cards and tape, the Team places User Stories on a wall or other surface, in order from small to large. For this, each Team member begins with a subset of User Stories from the overall Prioritized Product Backlog to place by relative size. This initial placement is done in silence. Once everyone has placed their User Stories on the wall, the Team reviews all of the placements and may move User Stories around as appropriate. This second part of the exercise involves discussion. Finally, the Product Owner will indicate some sizing categories on the wall. These categories can be small, medium, or large, or they may be numbered using Story Point values to indicate relative size. The Team will then move User Stories into these categories as the final step in the process. Some key benefits of this approach are that the process is very transparent, visible to everyone, and is easy to conduct.
Estimates for projects should be presented in ranges. Precise figures may give an impression of being highly accurate when in fact they may not be. Indeed, estimates by definition are understood not to be precisely accurate. Estimate ranges should be based on the level of confidence the Team has in each estimate. The range can be narrow when the Team is confident and wide when the Team is less confident.
