In order to comprehend the concepts of sizing and estimates, you should understand:
Relative size versus time estimates
Estimates don’t need to be accurate, they need to be consistent. Our
corrects for the inaccuracy of our estimates. Estimates on stories are meant to be relative to other estimates on stories. When engineers think of an estimate, they need to be comparing the story to other stories in the past in order to evaluate consistently.
Point sizing gets you to more predictable business outcomes
People are good at comparing size, but not at estimating an absolute value. The difference between a 1 and a 2 is insignificant; however, the difference between a 1 and a 5 is obvious.
If you assign 3
on a story, find a 1-point story nearby and assess whether this story is really 3 times as complicated as the smaller story. This is called triangulation, and it is vital to ensuring consistency. Do this periodically throughout planning, particularly for stories that generate discussion and disagreement.
It is helpful to have a set of stories nearby to make this comparison. You could create a point board in your planning area. On that board, list several previous stories and the estimates that were given to them. Try to have one or two stories for each possible estimate. When you are planning, you can note that Story A and Story J are each 5 points. Are these stories approximately the same in complexity?
You want your points to be forced into buckets with wide enough gaps between them that there is no need to argue over insignificant differences. Mike Cohn recommends either a Fibonacci-like sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) or a base-2 sequence (0, 1, 2, 4, 8, 16, 32, 64, 128) to ensure that the buckets are reasonable.
There are three basic factors you should consider when assigning points to a story: complexity, effort, and doubt.
Always estimate with the entire team, even if it is a little inconvenient. Use
cards or use the Estimation Board app.
Encourage your product owners to break up large stories before they are estimated.
When you start, all of your un-estimated stories appear in the left column. The team stands up and takes turns, each moving one card per turn. The team keeps moving, and if there is substantial disagreement, it is easy for a couple of people to discuss while everyone else continues sorting cards. Remote team members can participate, too.
Using this app is much faster than Planning Poker. It also helps emphasize the relative sizing work because the goal is just to group similarly-sized items, not to assign numbers.
Points versus hours
Traditional teams estimate all of their work in one unit type—regular time. These teams then spend too much time wondering why their estimates are off and struggling to get more accurate estimates. Many teams are able to bypass this struggle by estimating on two different estimation scales—points and hours.
stories in your
should be estimated in terms of their relative size. Once you have numbered your product
like this, you can measure how many of these units you are getting done each
by adding up the numbers for each accepted story. Over time, if you keep your team together, this velocity number should stabilize. If your velocity has been about 15 in the past, you can predict that if the team stays the same, you will get 15 done each iteration moving forward.
Why use hours for tasks then? Story estimates are arbitrary numbers after a couple of minutes of discussion. But when you plan tasks at the start of the iteration, you know the detailed
, the detailed
list, and maybe even who is doing the work. Estimating tasks in hours reflects the precision of the estimate.
For the maximum hours that should be assigned to a task within a story, we recommend one ideal developer day, which is about 6 hours. If a task takes more than a day, then the value of providing status at the
meeting is lost.
Why should we convert points into cost but not points into hours?
Hours are a much more granular estimate, and should not be relied on to provide cost. With points, you know generally if you are going to meet your iteration commitments. Task hours represent the daily commitments, and can be used at the end of the iteration to see if your point estimates are accurate.
A point is a relative, abstract value to represent size. We know the difference between tiny and huge. Story points are merely a representation of this concept. We recommend using a Fibonacci sequence to represent points.
How can you determine when an iteration can finish if there is no estimate in hours? Over time, your team will learn what their velocity is. Velocity is the average number of story points that can be completed in an iteration. With this value known (approximately), the team can plan within this figure, and know that they will most likely be able to finish. Velocity is not the same as speed.