Difference between revisions of "Relative estimation"
Jump to navigation
Jump to search
(Zeroth version.) |
(→Sources: += InfoQ » Ben Linders » Agile Estimation for Release Planning) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Oyster | {{Oyster | ||
|goal=harvest low hanging fruit for maximum return on investment | |||
|stage=Sparkle | |stage=Sparkle | ||
|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}}. | ||
|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). | ||
|therefore=Always estimate relative. Establish a common base for estimation across teams to allow for planning on a larger scale. | |||
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 full=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 {{p|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== | ==Sources== | ||
{{WebSourceListItem | |||
|url=http://www.mountaingoatsoftware.com/blog/establishing-a-common-baseline-for-story-points | |||
{{ | |site=Mountain Goat Software | ||
|person=Mike Cohn | |||
|title=Establishing a Common Baseline for Story Points | |||
}} | |||
{{WebSourceListItem | |||
|url=http://www.infoq.com/articles/agile-estimating-why-how | |||
|site=InfoQ | |||
|person=David Morris | |||
|title=Estimating on agile projects: what’s the story, what’s the point? | |||
}} | |||
{{WebSourceListItem | |||
|url=http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html | |||
|site=Alex Yakyma | |||
|title=Why Progressive Estimation Scale Is So Efficient For Teams | |||
}} | |||
{{WebSourceListItem | |||
|url=http://www.infoq.com/news/2014/04/estimation-release-planning | |||
|site=InfoQ | |||
|person=Ben Linders | |||
|title=Agile Estimation for Release Planning | |||
}} | |||
{{Source | {{Source | ||
|coder={{mvs}} | |coder={{mvs}} | ||
}} | }} | ||
{{tag|estimate}} | |||
Latest revision as of 05:08, 25 April 2014
…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
- Mountain Goat Software » Mike Cohn » Establishing a Common Baseline for Story Points
- InfoQ » David Morris » Estimating on agile projects: what’s the story, what’s the point?
- Alex Yakyma » Why Progressive Estimation Scale Is So Efficient For Teams
- InfoQ » Ben Linders » Agile Estimation for Release Planning