Differences

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

--- how_can_we_scale_our_estimating_approach_beyond_a_team [2019/01/14 14:53] – Fixed for readability hpsamios
+++ how_can_we_scale_our_estimating_approach_beyond_a_team [2019/01/16 13:27] – Added "where people typically end up" hpsamios
@@ Line 13: / Line 13: @@
 {{ :image001.png?600 |Why estimation epics, features, and stories}}
+(Note: Thanks to Steve Sanchez for the graphic.)
 There are two basic ways that you can scale estimates:
@@ Line 25: / Line 27: @@
 In practice, the two approaches really are not that far apart from each other. What you will find is that even with the summated approach, you will end up with features in the 10's (ie 10, 20, etc) and epics in the 100's. The hard part is getting people to really do relative size estimates that include a view of risk and complexity at all levels. As a general note SAFe starts with the "Summated Story point" approach, but it is not that specific over the long haul. In fact SAFe assumes a relative size approach (not duration) as it says "Start with day is a point then never look back").
-Note: Thanks to Steve Sanchez for the graphic.
+What this means is that in most cases that I have worked, organizations end up with the Pure Feature and Epic Points approach where Feature Points are the Fibonacci numbers times 10 (10, 20, 30, …, 130) and the Epic points are the Fibonacci numbers times 100 (100, 200, 300, …, 1300). The other thing that organizations do is limited the highest number to 13 or 20, no 100’s etc, with the idea that this encourages people to split the work up if it gets to this level. So if there is a Feature Point estimate of “this is more than 130”, the discussion is “Perhaps this is an Epic? Or perhaps we need to split the work so that it will fit in a quarter.” This is a good discussion to have.
 {{tag>Team Estimates Forecast FAQ Scaling Points}}