Thought of The Week: Absolute vs. Relative Estimation

Do you ever find yourself addressing questions about estimation?

In my experience, this topic still appears regularly in conversations with teams. For many practitioners, the distinction between absolute estimation and relative estimation remains unclear, as does the question of when each approach should be used.

Absolute estimation relies on standard units of measurement that are universally understood. When software developers estimate work using absolute methods, they typically use familiar units such as hours or days. These units are precise and commonly accepted, making them convenient when an individual is assessing their own workload.

Relative estimation, however, operates differently. Instead of relying on universally defined units, teams compare work items relative to one another. In this case, arbitrary scales are often used—story points, T-shirt sizes, or even playful metaphors such as dog breeds. These units are not intended to represent exact amounts of time; rather, they help teams express relative complexity, effort, and uncertainty.

To better understand relative estimation, consider a simple example outside the world of software development.

Imagine two colleagues—one from the United States and one from the United Kingdom—who want to quickly estimate the distance between Central Park in midtown Manhattan and Battery Park in downtown Manhattan. Each of them naturally thinks in different measurement systems: one in miles, the other in kilometers.

Instead of converting units or debating measurement standards, they could adopt a simpler approach. Looking at a map, they might decide to count the number of city blocks between the two locations and agree that one city block equals one “distance point.”

Once this shared reference scale is established, estimating distances between other locations becomes straightforward. They can simply count blocks—whether horizontally, vertically, or diagonally—and express the result in distance points. In this way, they bypass the need for precise measurement and focus instead on relative comparison.

The same principle applies in software product development.

• When a developer works largely independently—without pair programming, mobbing, swarming, or other collaborative practices—and simply needs to determine whether there is enough capacity to complete a task, using ideal hours or days is often sufficient. Introducing a relative estimation scale in such situations may unnecessarily complicate the process. The work does not require shared interpretation or collective calibration with others.
• It is also important to distinguish between measuring outcomes and outputs. A full-stack developer who works across multiple layers of the system may be able to measure the tangible outcome of their work because it results in a potentially shippable increment. By contrast, a highly specialized contributor—such as someone responsible only for a backend component—may measure only the output of their work, since their contribution alone may not produce a deliverable product increment.
• When developers work as a team, relative estimation becomes more valuable.
• If a team has developed confidence in its ability to collaboratively size work and deliver reliably, it may choose to use story points as a coarse-grained estimation scale. In such cases, breaking work down into smaller tasks measured in hours may not be necessary.
• More important than the number itself is the discussion that leads to it. Teams benefit from focusing on the well-known 3C model—Card, Conversation, and Confirmation—rather than obsessing over numeric precision. Unfortunately, many teams fall into the trap of chasing numbers for reporting or performance metrics while missing the true purpose of estimation: developing a shared understanding of the work.
• For teams that are still building confidence in their estimation capabilities, a hybrid approach may be helpful. They might begin by assigning story points to user stories as a form of coarse relative sizing. Afterward, they may break the work down into tasks estimated in hours or days. Over time, this additional step can help the team observe whether their story-point estimates correlate consistently with the actual time spent.
• In mature, stable teams that work together over long periods, such correlations often begin to resemble a bell-shaped distribution of effort across work items. This pattern is much less common in temporary or unstable project teams whose membership frequently changes.
• Finally, when a development team becomes highly consistent in delivering similarly sized work items, estimation may become even simpler. Instead of assigning story points, the team may rely primarily on counting completed work items and observing throughput. This is a common practice in Kanban environments, where forecasting is based on flow metrics rather than abstract estimation scales.

For relative estimation to function effectively in software product development, several conditions must be present.

1. First, teams must possess a clear conceptual understanding of relative estimation and how it differs from absolute measurement.
2. Second, relative estimation requires more than one person. A single individual does not need to normalize their perception of effort with anyone else and can simply estimate using standard units such as hours or days.
3. Third, the practice works best when team members are cross-functional or at least broadly knowledgeable about each other’s work. Ideally, they collaborate closely and develop a shared understanding of the product and its complexity over time.
4. Fourth, participants must truly belong to the same team and share responsibility for outcomes. In large-scale product development environments, multiple teams may even refine and estimate work collaboratively.
5. Finally—and perhaps most importantly—relative estimation requires an environment of trust. If individuals intentionally inflate or deflate estimates for personal advantage, the entire process quickly loses credibility. Honest collaboration and shared ownership are essential.

The illustrations and cartoons that accompany this topic can be helpful in visualizing common estimation challenges and misconceptions. Sometimes, a simple visual metaphor reveals more about estimation dysfunction than lengthy theoretical explanations.