how_can_we_scale_our_estimating_approach_beyond_a_team
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
how_can_we_scale_our_estimating_approach_beyond_a_team [2019/01/10 14:20] – hpsamios | how_can_we_scale_our_estimating_approach_beyond_a_team [2019/01/16 13:27] – Added "where people typically end up" hpsamios | ||
---|---|---|---|
Line 10: | Line 10: | ||
* We are [[what_is_the_basis_of_our_estimating_process|using a relative team sized story point based estimating approach]]. | * We are [[what_is_the_basis_of_our_estimating_process|using a relative team sized story point based estimating approach]]. | ||
- | + | In general there is a different focus in the " | |
- | In general there is a different focus in the " | + | |
{{ : | {{ : | ||
- | There are two basic ways that you can scale these estimates: | + | (Note: Thanks to Steve Sanchez for the graphic.) |
+ | |||
+ | There are two basic ways that you can scale estimates: | ||
* Pure Feature and Epic points which are used as an estimate: With this approach you use a similar process that you would use with story points. In other words you would do a team based relative size estimate to generate " | * Pure Feature and Epic points which are used as an estimate: With this approach you use a similar process that you would use with story points. In other words you would do a team based relative size estimate to generate " | ||
Line 22: | Line 23: | ||
* Summated Story points to create Feature and Epic estimates: Based on a common understanding of the size of a story point, the idea here is that features are estimated in terms of the number of story points it would take to complete the work, and similarly for epic. So for example, if we look at a feature and as we do the estimating we would say "this feature is about the same amount of work as this 60 point feature, so we'll call this a 60 for the estimate. | * Summated Story points to create Feature and Epic estimates: Based on a common understanding of the size of a story point, the idea here is that features are estimated in terms of the number of story points it would take to complete the work, and similarly for epic. So for example, if we look at a feature and as we do the estimating we would say "this feature is about the same amount of work as this 60 point feature, so we'll call this a 60 for the estimate. | ||
* Pros: One benefit of this approach is that you can start using data immediately. If, for example, you want to start managing epics at the portfolio level now, you can quickly create estimates and understand capacity even if you do not have all the teams in place. | * Pros: One benefit of this approach is that you can start using data immediately. If, for example, you want to start managing epics at the portfolio level now, you can quickly create estimates and understand capacity even if you do not have all the teams in place. | ||
- | * Cons: The main downside of this approach is that to work it needs to have a common understanding of a point. Many start with "a day equals a point" with the result this can quickly turn into a pure duration based estimate with all the problems that entails. Another problem occurs when one teams velocity is significantly different (ie orders of magnitude different) from other teams as while each of the teams can work their own estimates and velocity, when you summate very large numbers from one team can completely swamp other team's numbers which means it is hard to understand capacity of the multi-team train. | + | * Cons: The main downside of this approach is that to work it needs to have a common understanding of a point. Many start with "a day equals a point" with the result this can quickly turn into a pure duration based estimate with all the problems that entails. Another problem occurs when one Team' |
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 " | 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 " | ||
- | Note: Thanks | + | 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 |
{{tag> | {{tag> |
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_can_we_scale_our_estimating_approach_beyond_a_team.txt · Last modified: 2021/12/08 13:47 by 127.0.0.1