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 revision | Last revisionBoth sides next revision | ||
how_can_we_scale_our_estimating_approach_beyond_a_team [2019/01/16 13:27] – Added "where people typically end up" hpsamios | how_can_we_scale_our_estimating_approach_beyond_a_team [2019/01/21 09:08] – Reading enhancements hpsamios | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== How Can We Scale Our Estimating Approach Beyond a Team? ====== | ====== How Can We Scale Our Estimating Approach Beyond a Team? ====== | ||
- | Often, you need to provide estimates for items of work that are beyond the size of a typical | + | Often, you need to provide estimates for items of work that are beyond the size of a typical |
The question therefore is "How do you go about getting size information for these bigger pieces of work?" | The question therefore is "How do you go about getting size information for these bigger pieces of work?" | ||
Line 7: | Line 7: | ||
For the sake of discussion we are going to make a couple of assumptions: | For the sake of discussion we are going to make a couple of assumptions: | ||
- | * We are going to use the basic SAFe structure of stories | + | * We are going to use the basic SAFe structure of Stories |
* 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 "why we estimate" | + | In general there is a different focus in the "why we estimate" |
{{ : | {{ : | ||
Line 16: | Line 16: | ||
(Note: Thanks to Steve Sanchez for the graphic.) | (Note: Thanks to Steve Sanchez for the graphic.) | ||
- | There are two basic ways that you can scale estimates: | + | There are two basic ways to 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 use Team based relative size estimate |
* Pros: In many ways, this approach is a [[where_did_this_estimation_approach_come_from|" | * Pros: In many ways, this approach is a [[where_did_this_estimation_approach_come_from|" | ||
- | * Cons: The main downside of this approach is that it will take time to get useful (in terms of forecasting) data. Just like a team has to wait an iteration | + | * Cons: The main downside of this approach is that it will take time to get useful (in terms of forecasting) data. Just like a Team has to wait an Iteration |
- | * Summated Story points | + | * Summated Story Points |
- | * Pros: One benefit of this approach is that you can start using data immediately. If, for example, you want to start managing | + | * Pros: One benefit of this approach is that you can start using data immediately. If, for example, you want to start managing |
- | * 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's velocity is significantly different (ie orders of magnitude different) from other Team's as, while each of the Teams can work their own estimates and velocity, when you summate very large numbers from one Team they 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 you need to have a common understanding of a Story 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's velocity is significantly different (ie orders of magnitude different) from other Team's as, while each of the Teams can work their own estimates and velocity, when you summate very large numbers from one Team they can completely swamp other Team's numbers which means it is hard to understand capacity of the multi-Team Train. |
- | 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 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 |
- | 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. | + | What this means is that in most places |
{{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