User Tools

Site Tools


why_do_we_use_story_points_instead_of_hours

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
why_do_we_use_story_points_instead_of_hours [2019/01/21 06:33] – [Estimation is Continually Refined] hpsamioswhy_do_we_use_story_points_instead_of_hours [2019/01/21 08:47] – Edited to fix English hpsamios
Line 1: Line 1:
 ====== Why Do We Use Story Points Instead of Hours or Days? ====== ====== Why Do We Use Story Points Instead of Hours or Days? ======
  
-Story points should be used because people are naturally better at relative estimation instead of actual estimation.  Relative estimation with story points:+Story Points should be used instead of absolute hours because people are naturally better at relative estimation. Relative estimation with story points:
  
-  * Takes less time, +  * Take less time, 
-  * Provides enough accuracy and precision for organizations to forecast and teams to plan, +  * Provide enough accuracy and precision for organizations and Teams to forecast and plan, 
-  * Can scale from individual teams to team-of-teams and portfolio.  +  * Can scale from individual Teams to Team-of-Teams and Portfolios.  
  
 But Story Points are not equal to hours. A lot of people like to equate hours or days with Story Points. Sometimes this is because there: But Story Points are not equal to hours. A lot of people like to equate hours or days with Story Points. Sometimes this is because there:
Line 11: Line 11:
   * Is a misunderstanding of what Story Points are, or   * Is a misunderstanding of what Story Points are, or
   * Is starting guidance we get when first doing estimates, or   * Is starting guidance we get when first doing estimates, or
-  * Are Teams have small, well known, low complexity work where they actually know how many hours it takes them to implement.+  * Are Teams that have small, well known, low complexity work where they actually know how many hours it takes them to implement.
  
- +If, for example, you are using SAFe, and have never done the Story Point approach before, SAFe introduces the idea of standardizing points where "the shared understanding of 1 story point 'is '~ 1 day of effort to develop & test a story'". This ensures we were able to do reporting at higher levels by rolling up numbers. SAFe also establishes 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 Iteration. The training material indicates that this was a starting point.
-If, for example, you are using SAFe, and have never done the Story Point approach before, SAFe introduces the idea of standardizing points where "the shared understanding of 1 story point 'is '~ 1 day of effort to develop & test a story'". This ensures we were able to do reporting at higher levels by rolling up numbers. 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 Iteration. 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. 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 time (hours or days), we should stop calling them Story Points. After all, they are just “ideal days” with all the inherent problems. [[http://www.agilejournal.com/articles/columns/column-articles/6458-lets-stop-the-wishful-thinking|Daryl Kulak]] says:+To be clear, if the estimate is really just a proxy for time (hours or days), we should stop calling them Story Points. After all, they are just “ideal days” or "ideal hours" with all the inherent problems. [[http://www.agilejournal.com/articles/columns/column-articles/6458-lets-stop-the-wishful-thinking|Daryl Kulak]] says:
  
 <WRAP box>If a development team is equating some number of hours to a storypoint, it is missing the point (pun intended). Saying, “Thirty hours equals one point” is ridiculous. If you’re doing that, just use hours for goodness sake. You haven’t gained anything from storypoints except to be able to claim to be doing “agile.”</WRAP> <WRAP box>If a development team is equating some number of hours to a storypoint, it is missing the point (pun intended). Saying, “Thirty hours equals one point” is ridiculous. If you’re doing that, just use hours for goodness sake. You haven’t gained anything from storypoints except to be able to claim to be doing “agile.”</WRAP>
 +
 +Here are some things to understand when using Story Points instead of a more traditional approach to estimating.
  
 ===== Story Points and Velocity ===== ===== Story Points and Velocity =====
Line 44: Line 45:
 {{ mapping_hours_to_risk_etc.png?direct&600 |}} {{ mapping_hours_to_risk_etc.png?direct&600 |}}
  
-This chart is an example of how teams develop their view of "size." The Team that developed this chart had specifics about what they thought size meant, including complexity and risk. I sanitized it for the article. So, for example, for this Team "risk" meant "known risks" while "uncertainty" was "unknown unknowns" (and there was more of this the further out the work was.) In their minds it was not the same thing. To be clear+This chart is an example of how teams develop their view of "size." The Team that developed this chart had specifics about what they thought size meant, including complexity and risk. I sanitized it for the article. So, for example, for this Team "risk" meant "known risks" while "uncertainty" was "unknown unknowns" (and there was more of this the further out the work was.) In their minds it was not the same thing. To be clear if your Team formalizes the development of a chart like this, their chart will look different based on the work, your Team’s make-up, etc.
- +
-<WRAP Box>Your Team’s chart will look different based on the work, your Team’s make-up, etc.</WRAP>+
  
 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. 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.
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/why_do_we_use_story_points_instead_of_hours.txt · Last modified: 2020/07/13 06:51 by hans