how_should_we_update_our_estimates
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| how_should_we_update_our_estimates [2019/01/14 13:54] – created hpsamios | how_should_we_update_our_estimates [2022/08/15 12:28] (current) – hans | ||
|---|---|---|---|
| Line 3: | Line 3: | ||
| Or "When Should We Update Our Estimates?" | Or "When Should We Update Our Estimates?" | ||
| - | One of the interesting things that happens when we estimate using Team based Story Point estimates is that old habits die hard. If, for whatever reason, we do the estimate and then follow it up with the work, if it turns out (typically) that there was a lot more work than originally estimated, then we have this tendency to want to go back and improve | + | Old habits dies hard. One of the interesting things that happens when we estimate using Team based Story Point estimates is that once the work is complete, Teams want to update |
| This is a mistake. | This is a mistake. | ||
| - | The reality is that no amount of additional planning would have resulted in a better estimate. In fact the evidence indicates otherwise; estimates get worse the more time you spend on it (mainly because you are building guesses on top of guesses). It is simply wrong to " | + | The reality is that no amount of additional planning would have resulted in a better estimate. In fact the evidence indicates otherwise; estimates get worse the more time you spend on it (mainly because you are building guesses on top of guesses |
| - | What this tells you is that you should not update a record of the estimate once you have started real work on it. That way an estimate stays an estimate, and has the same basis (and is good as) as any other estimate that we have in the system. Using this basis compare all the estimates, safe in the knowledge that they have the same status - "we haven' | + | What this tells you is that you should not update a record of the estimate once you have started real work on it. That way an estimate stays an estimate, and has the same basis (and is good as) as any other estimate that we have in the system. Using this basis we can compare all the estimates, safe in the knowledge that they have the same status - "we haven' |
| There is nothing wrong with collecting information about how much effort something actually takes; just don't call that an " | There is nothing wrong with collecting information about how much effort something actually takes; just don't call that an " | ||
| - | What does this mean in a practical sense? Lets take a Story as a starting point. Associated with this Story should be a field which stores the " | + | What does this mean in a practical sense? Lets take a Story as a starting point. Associated with this Story should be a field which stores the " |
| - | Now the Team starts working the Story. | + | * Perhaps |
| + | * Perhaps there was increased clarity associated with the acceptance criteria. | ||
| + | * Perhaps we invested in some enablement | ||
| + | * Perhaps .... | ||
| - | This kind of thinking applies the higher level structures (Epics / Features) as well. The basic rule is that you shouldn' | + | All these things might necessitate an update to the Story estimate. |
| + | |||
| + | Now the Team starts working the Story. Perhaps they committed to it during Iteration (Sprint) Planning. The Team is decomposing the work, determining who does what etc. At this point you should not update the " | ||
| + | |||
| + | This kind of thinking applies the higher level structures (Epics / Features) as well. | ||
| + | |||
| + | The basic rule is that you shouldn' | ||
| + | |||
| + | ====== Want To Know More? ====== | ||
| + | |||
| + | * [[our_estimates_are_terrible|Our Estimates are Terrible!]] | ||
| {{tag> | {{tag> | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_should_we_update_our_estimates.1547502894.txt.gz · Last modified: 2020/06/02 14:27 (external edit)