- Estimation Techniques Tutorial
- Estimation Techniques Resources
- Selected Reading
Planning Poker Estimation
- May 16, 2013 Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down. For a complete break down on the points vs.
- Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds. Story point being a coarse grained or rough estimation technique, it helps in long term planning like release planning.
Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2.
Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in Scrum.
Planning Poker combines three estimation techniques − Wideband Delphi Technique, Analogous Estimation, and Estimation using WBS.
Planning Poker was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in his book 'Agile Estimating and Planning”, whose company trade marked the term.
Planning Poker Estimation Technique
In Planning Poker Estimation Technique, estimates for the user stories are derived by playing planning poker. The entire Scrum team is involved and it results in quick but reliable estimates.
Planning Poker is played with a deck of cards. As Fibonacci sequence is used, the cards have numbers - 1, 2, 3, 5, 8, 13, 21, 34, etc. These numbers represent the “Story Points”. Each estimator has a deck of cards. The numbers on the cards should be large enough to be visible to all the team members, when one of the team members holds up a card.
One of the team members is selected as the Moderator. The moderator reads the description of the user story for which estimation is being made. If the estimators have any questions, product owner answers them.
Each estimator privately selects a card representing his or her estimate. Cards are not shown until all the estimators have made a selection. At that time, all cards are simultaneously turned over and held up so that all team members can see each estimate.
In the first round, it is very likely that the estimations vary. The high and low estimators explain the reason for their estimates. Care should be taken that all the discussions are meant for understanding only and nothing is to be taken personally. The moderator has to ensure the same.
The team can discuss the story and their estimates for a few more minutes.
The moderator can take notes on the discussion that will be helpful when the specific story is developed. After the discussion, each estimator re-estimates by again selecting a card. Cards are once again kept private until everyone has estimated, at which point they are turned over at the same time.
Repeat the process till the estimates converge to a single estimate that can be used for the story. The number of rounds of estimation may vary from one user story to another.
Benefits of Planning Poker Estimation
Planning poker combines three methods of estimation −
Expert Opinion − In expert opinion-based estimation approach, an expert is asked how long something will take or how big it will be. The expert provides an estimate relying on his or her experience or intuition or gut feel. Expert Opinion Estimation usually doesn’t take much time and is more accurate compared to some of the analytical methods.
Analogy − Analogy estimation uses comparison of user stories. The user story under estimation is compared with similar user stories implemented earlier, giving accurate results as the estimation is based on proven data.
Disaggregation − Disaggregation estimation is done by splitting a user story into smaller, easier-to-estimate user stories. The user stories to be included in a sprint are normally in the range of two to five days to develop. Hence, the user stories that possibly take longer duration need to be split into smaller use-Cases. This approach also ensures that there would be many stories that are comparable.
Capacity (time) & velocity (points) based planning
(Scenario 1) Imagine you have a new team with members that have hardly worked together in a scrum team before. Perhaps they are adopting scrum, or that the team has been pulled together from different sources.
As there is no history of velocity and the initial relationship of points to sprint length is going to be volatile for the first few sprints, it would be tempting to switch to capacity based planning where we talk about how much time it will take to execute the tasks as there is a stronger correlation to time taken during the earlier sprints.
(Q1) If capacity based planning is used, would the team still estimate story points in order to establish velocity on hindsight and then subsequently switch over to velocity based planning?
(Scenario 2) With velocity planning where points are awarded to stories which are reviewed in the 'What' half of sprint planning, during the 'How' part if the team then break down the stories into tasks of a day or less in order that progress can be measured, and they may subsequently re-negociate with the PO on how much they can deliver:
(Q2) ...are they not effectively capacity planning in any case?
Development Teams must deliver value, and should therefore be careful to avoid becoming story point accountants.
During Sprint Planning, it's best to look at the forecast of work in aggregate and decide 'is the Sprint Goal for this work achievable?'. Story points are indicators that can assist the team in making this decision. They are not a method of calculation.
I'd encourage a team from the beginning to take this more holistic view. The forecast of work may be modest until experience is gained; if it proves too conservative then additional work can be brought forward.
Planning Poker Story Points
- Log in or register to post comments
Hi Damian,
Planning Poker Numbers
For a new Scrum team with no history of velocity, one common way to forecast a team’s velocity is to have the team pull PBIs one by one to determine what PBIs the Team could deliver during a single sprint.
There are 2 way to perform capacity based planning:
1. Estimate how much time it will take to have a PBI be Done.
2. Decompose each PBI to actionable tasks. Estimate how much time it will take to execute the tasks.
The Team could simply add the hour each PBI/task cost and compare to Team’s capacity to determine what PBIs it could commit.
If the forecasting or commitment seems reasonable, the Team could simply add the size of the PBIs pulled to Sprint Backlog and use that as the Team’s forecasted velocity.
There are no switch problem, but using Velocity from now on.
There is a disadvantage by using capacity based planning or idea hour as estimating unit of PBIs.
Image that a PBI’s size is 24 hours in Product Backlog.
The team pull it to Sprint backlog and decompose to 5 Tasks listed as follows:
Task1: 6 hrs.
Task2: 4 hrs.
Task3: 8 hrs.
Task4: 5 hrs.
Task5: 4Hrs
Total: 27 hrs.
There should be a confusing between a PBI and tasks decomposed.
Estimates are not commitments.
For planning purpose, velocity during the “what” part is most useful when expressed as a range. During the “how” part, if the cost is out of range, they may re-negotiate with the PO to remove several item or just start the sprint. Velocity is measured by adding the size of the PBIs that are “COMPLETED” by the end of the sprint. Velocity does not include the size numbers of partially completed PBIs.
As the Team builds up a history of actual velocities, an effective velocity range will be used as a planning tool and as a team diagnostic metric.
- Log in or register to post comments
Each new team starting together has similar issue. To mitigate risk of unknown you can coach team to cut risk horizon and shorten the sprint length to expose to risks and unknown faster. After couple of sprint you will have some kind of feeling what team can forecast during sprint. To minimize the risk during sprint planning you can coach team to slice PBI into multiple small task easier to finish and track - which will in the end reinforce team efforts and improve their morale to get things done.
What kind of knowledge gives unknown velocity prediction in terms of initiative team will try to develop? Is it a try to make sure team is not estimating more than stakeholders assumed it will take?
After each three sprint you will have rolling average to try to predict future.
Agile Story Points Planning Poker
- Log in or register to post comments