Why Do We Use Story Points Instead of Hours or Days?

Or “But a Story Point is the same as a Day, isn't it?”


A lot of people like to equate hours or days with Story Points. Some times this is because people don't understand what Story Points are. Other times its because of the starting guidance we get when first doing estimates. So for example if you are using SAFe and the agile approach, since we had not done the Story Point approach before, and to ensure we were able to do reporting at higher levels, we introduced the idea of standardizing points as “the shared understanding of 1 story point” is “~ 1 day of effort to develop & test a story”. We also established the initial velocity for the Team by multiplying the number of people on the Team (not including PO and SM) by 8 (days) and then adjusting the result down by subtracting the number of days that people would not be available during a Sprint. The training material indicated that this was a starting point.

The problem is that many people are still using this understanding when estimating stories by saying things like “a day is equals a point and so since this item is about 10 days, the estimate is 10 points”. They then fudge the number to an 8 or 13 because “we are only allowed to use the Fibonacci numbers.” This is not the intent, and if you head in this direction there is no benefit to using story points.

To be clear, if the estimate is really just a proxy for days, we should stop calling them Story Points. After all, they are just “ideal days” with all the inherent problems.

Story Points Reflect More Than Duration

But story points are not a proxy for days. For example, Team velocity is expected to increase over time as the Team learns how to deliver value more effectively. If this is grounded in day-based estimates, you cannot expect velocity to increase as the reality is that there is only so much time available in a two week period.

Sure, “how long” you expect something to take is part of the estimate, but you also want to factor in risk, complexity and uncertainty. For example, if the work looks like it will take the Team a day to do, but there is a lot of risk involved, then the Team might want to give a higher (not 1) estimate – say a 2 or a 3. If the duration is expected to be 8 Team days, and it is low risk and complexity, the Team might consider the estimate to be an 8, or the Team might say “we are rubbish at estimating week long efforts so let’s give it a 13 to address this uncertainty.” In this example the 13 hopefully leads to a discussion about splitting the story to improve its chances of delivery.

Estimates should be relative to something; a known piece of work. Start with a 1 sized piece of work (about a day, low risk, low complexity, and low uncertainty) that the whole Team can understand. Then, as you do other estimates the Team talks in terms of “in comparison to this 1 sized piece of work, I think this is about 3 times bigger, so this is a 3.” Perhaps you also identify another sized piece of work, say a common understanding of an 8 sized story. Having an understanding of two different sized stories will help the Team triangulate the estimate for any new stories – “its bigger than this 1 sized story, but smaller than this 8 sized story so it a …” Some Teams call these known stories their “keystone” stories.

Over time, as Teams do more estimating, the Team will start to build up a table in their heads:

Each Team will have a different view of the factors that contribute to “medium risk” but within a Team they will have a shared understanding. So one Team might say “if it involves new screen then, at a minimum, it is an 8 because we need to work UX issues, work closer with the customer, …” Another team might have UX expertise and so this may not be a reason to differentiate for that team. But they may have an approval process that seems to slow things down, so stories that have this approval step are larger. Each team will have a different view of the factors that effect “size” of work for them.

What is really cool about estimating this way is that you will establish a stable Team velocity over time which will help the Team make and meet commitments. As you determine future work, you can rely on the historical velocity of the Team since the numbers already factor in different risk, complexity and uncertainty profiles.

Want to Know More?

Use the following URL for manually sending trackbacks: http://www.hanssamios.com/dokuwiki/lib/plugins/linkback/exe/trackback.php/why_do_we_use_story_points_instead_of_hours
how_do_i_convert_points_and_velocity_to_dollars, 2016/09/27 14:47 (Trackback)
How Do I Convert Points and Velocity to Dollars? Or “How do I figure out how much I've spent on something?” Or “Do we still need to track time in a time tracking system for progress reporting?” Premise One base idea with agile to focus on completion of work rather than the effort it takes to get the work done. So, for example, we track the remaining work on a story rather than the counting the number of hours we spent on a story. This makes sense because while the effort might be interesting…
Why Not Just Track Hours Like We Traditionally Do So what are the problems associated with using tracking hours? Some of the problems are: * With agile we only plan to 5 or 6 hours a day (or some other amount depending on what people end up doing). We could ask teams to record “everything” but that is an overhead (tasks for everything like doing email). This is the purview of a “time tracking” system. We could just multiple all numbers by 8/5 to get to something more real, but is this any be…
You could leave a comment if you were logged in.
  • why_do_we_use_story_points_instead_of_hours.txt
  • Last modified: 2018/11/07 14:59
  • by hpsamios