Difference between revisions of "Relative estimation"
(To process++) |
m (terse/full) |
||
| Line 3: | Line 3: | ||
|theme=Agile, Scrum | |theme=Agile, Scrum | ||
|context=one or more {{p|development team}}s working on {{p|collaborative product discovery}}. | |context=one or more {{p|development team}}s working on {{p|collaborative product discovery}}. | ||
| | |goal=harvest low hanging fruit for maximum return on investment | ||
|wish=Consistent estimation of effort makes planning a breeze. | |wish=Consistent estimation of effort makes planning a breeze. | ||
|so=Always estimate relative. | |||
|wish full=Consistent estimation of effort makes planning a breeze. | |||
|background=The idea of relative estimating being better than absolute is not merely a premise. It has been shown by Lederer and Prasad in “A Causal Model for Software Cost Estimating Error” (1998) and Vicinanza et al. in “Software Effort Estimation: An Exploratory Study of Expert Performance” (1991). | |background=The idea of relative estimating being better than absolute is not merely a premise. It has been shown by Lederer and Prasad in “A Causal Model for Software Cost Estimating Error” (1998) and Vicinanza et al. in “Software Effort Estimation: An Exploratory Study of Expert Performance” (1991). | ||
Velocity is “the great equalizer”, according to {{author|Mike Cohn}}, because it is what lets a team be able to successfully plan a project as long as their estimates are consistent (even if there is systematic error in those estimates). Being consistent is much easier to achieve and this allows teams to create plans. | Velocity is “the great equalizer”, according to {{author|Mike Cohn}}, because it is what lets a team be able to successfully plan a project as long as their estimates are consistent (even if there is systematic error in those estimates). Being consistent is much easier to achieve and this allows teams to create plans. | ||
|therefore=Always estimate relative. Establish a common base for estimation across teams to allow for planning on a larger scale. | |therefore full=Always estimate relative. Establish a common base for estimation across teams to allow for planning on a larger scale. | ||
}} | }} | ||
==To process== | ==To process== | ||
Revision as of 10:13, 16 June 2013
…one or more development teams working on collaborative product discovery.
✣ ✣ ✣
Consistent estimation of effort makes planning a breeze.
The idea of relative estimating being better than absolute is not merely a premise. It has been shown by Lederer and Prasad in “A Causal Model for Software Cost Estimating Error” (1998) and Vicinanza et al. in “Software Effort Estimation: An Exploratory Study of Expert Performance” (1991).
Velocity is “the great equalizer”, according to Mike Cohn, because it is what lets a team be able to successfully plan a project as long as their estimates are consistent (even if there is systematic error in those estimates). Being consistent is much easier to achieve and this allows teams to create plans.
Therefore:
Always estimate relative. Establish a common base for estimation across teams to allow for planning on a larger scale.
✣ ✣ ✣
✣ ✣ ✣
To process
- A story that would have been estimated as 6 two sprints ago should still be estimated as 6 today.
- You build your reference as you go.
- Use planning poker for consistent team estimation.
- Fibonacci numbers: something is a 3, another thing is more, but is it less than twice as much (then it is a 5) or is it more than twice as much (then it is an 8).
Sources