Do you ever have to handle questions about estimation?
In my experience, this topic still comes up in conversations frequently, and it seems that for many teams it is still not clear, how an absolute and relative estimation differ from each other, and when each one should be used.
Usually, an absolute estimation is based on units of measure that are universal and clearly understood by everyone involved in estimation. When software developers estimate work, absolute units of measure could be used – usually, days and hours.
On the other hand, when teams (not just one developer) perform relative estimation, they can use arbitrary units of measure, such as, story points, T-shirt sizes or dog breeds.
Here is a simple example of relative estimation that does not involve software development:
If two colleagues, one from the US and one from the UK, want to quickly assess a distance between the Central Park in midtown Manhattan and Battery Park in downtown Manhattan, they may face the challenge of relating miles (US) to kilometers (UK), used by each colleague, respectively.
In this situation, colleagues can simply count the number of city blocks, from one location to another, and arbitrarily, decide that one city block is equal to one distance point. Then, it would become, relatively easy, to coarse-estimate any distance between any other city landmarks, by simply looking at a map and counting blocks/distance points: horizontally, vertically and diagonally.
What estimation scale is best to choose in software product development?
- If a developer works individually (no peer-programming/mobbing, swarming), and can simply assess if he has enough capacity to finish on time, he can just use ideal days/hours. There is no need to overcomplicate things with a relative scale, since work does not need to be understood, or contributed to, by others. One thing to note here is that while a full-stack developer would be measuring a real outcome of his work, a single-function specialist, most likely, would be able to measure only an output, since his work would not be potentially shippable at the end of the sprint (e.g. just a back-end component).
- If a team of developers works together and they are very confident in their ability to relatively size and deliver on target, they can use story points, as a coarse-grained, relative sizing method. It may not be necessary for them to break down work items any further (e.g. tasks). Here, it is very important to focus on the “3C”: Card, Conversation, Confirmation, more so, than on producing a number (many teams still chase numbers, to produce metrics, while missing out on having a conversation and developing a shared understanding).
- If a development team is not very confident in their ability to size work and deliver on target, they may use story points, as an initial 3C/coarse-grained relative sizing method at e.g. user story level, and then, in addition, apply days/hours, at a task-level. This could help confirming that over time, their story point estimation, produces a consistent binomial distribution (bell-shaped curve) of days/hours that are spent on each work item. This should be true for stable, long-lived product teams but not so much for unstable, short-lived project teams.
- If a development team is very consistent in their estimation and sizing work items, then a count of actual work items could be sufficient to estimate and forecast. Story points may not be even needed. This is what Kanban teams usually do.
What are some of the most important conditions for relative estimation in software product development?
- Mandatorily, theoretical/conceptual understanding of relative estimation and how it differs from absolute estimation
- Minimally, two people+, trying to ‘normalize’ their understanding of time/volume and complexity of work. Remember: A single worker can simply estimate in traditional measurement units (hours, miles, pounds). There is no need for ‘normalize’ with anyone. No need for a fancy scale
- Ideally, cross-functional, T/M-shaped workers, capable of performing multiple types of work on the same team. At a minimum, people understanding each other’s work and working side-by-side, for a long time
- Unquestionably, people that officially belong to the same team and share ownership/responsibilities with others. For large-scale, multi-team product development, teams are expected to refine and estimate together
- Unequivocally, people not trying to inflate or deflate estimations for their own selfish benefit, and working in trusty environments
 |
 |
 |
 |