agile estimation

Last modified: October 18th, 2013

Accurate estimation in software development has proven challenging, to say the least.  Agile software development teams, in an effort to overcome these inherent challenges in estimation, focus primarily on consistent estimation as opposed to accurate estimation.  In order to do so, teams must estimate in terms which allow them to more effectively target consistency.  So instead of trying to answer the question “how long?” teams answer the question “how big?”  The rationale behind this is that it is much easier for a team to determine with relative consistency whether one story is larger or smaller than another, than for it to look at a story and say with confidence that it will take “X” hours (or person-days, or some other unit of time).

Different organizations use different units to indicate the relative size of a story - many use numeric scales of “story points,” while some use T-shirt sizes (small, medium, large, extra-large) or other, more abstract units.  Some organizations use “ideal days,” which is intended to convey how long it would take to deliver a story if there were no interruptions (meaning that 2 ideal days might actually work out to be 5 or more calendar days).  Because this approach retains a time component, and thus can still be construed to represent “how long,” a common use of this approach is as a transition from time estimates to point-based estimates.

There are at least two advantages to estimating relative size.  First, it can be done quickly and collaboratively by the team members who will eventually be implementing the stories.  This helps teams limit the time they invest in detailed requirements, while having a broad range of expertise weigh in on the estimation.  Secondly, as a team estimates together over time, a self-referencing scale emerges.  If a team happens to be using a scale of 1 to 5, and estimates together over multiple iterations, stories that receive a size estimate of 3 will tend to reflect the same degree of size and complexity, as will those that are estimated at 5, and so on.  This consistency in estimation, coupled with a consistent iteration cadence, is what will enable an organization to answer the “how long?” question and confidently plan releases based on the demonstrated, historically accurate throughput capability (velocity) of a team, rather than on padded guesses as to elapsed time.

When calculating velocity, size is estimated, velocity is measured, and duration is derived.  So if a team with a demonstrated stabilized capability of delivering 20 story points of work per 2-week iteration (its velocity) has estimated all of the items in a release backlog, and the sum of those estimates equals 120 story points, we can estimate that it will take approximately six 2-week iterations to deliver all of the items in that backlog.  The answer to “how long?” in this case is an estimated 12 weeks.  In the case of a single story, if the story is sized such that it will fit into an iteration (this will differ from team to team, and a team quickly learns what this size is), the answer to how long it will take to deliver that story is “one iteration.”

Estimation (VersionOne)
Agile Estimation
(Eclipse Wiki)
Agile Estimating and Planning (Mike Cohn)
User Story Estimation Techniques
(Jay Fields for InfoQ)
Agile Estimation, Part 1 (Mike Cohn - video)
Agile Estimation (Alex Hung - video)
Estimating (James Shore)