Agile Glossary

Relative Estimation

What is Relative Estimation?

Relative estimation is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by a grouping of items of equivalent difficulty.

Also Known As

Relative estimation is the basis of several closely related variants, such as “silent grouping” or “affinity estimating“. Some teams use non-numerical scales as a way to “force” relative estimation and the names of the corresponding techniques reflect the scale: “tee-shirt sizing” is common, and more exotic scales such as fruit or dog points are also found, possibly more for novelty value than for any real gains in clarity.

Expected Benefits

  • relative estimation, consistent with estimation in units other than time, avoids some of the pitfalls associated with estimating in general: seeking unwarranted precision, confusing estimates for commitments
  • there is a persistent claim in the Agile community that research in the psychology of planning shows that people fare better at relative than absolute estimation; in fact, the grounding for this claim is at best, tentative

Origins

  • 2001: an article by Bill Wake points out two distinct flavors of estimation in use among Agile teams, relative and absolute estimation

Academic Publications

The following references are cited in Mike Cohn’s “Agile Estimating and Planning” in a discussion of the benefits of relative estimation:

  • In a 2001 article by Miranda, “Improving Subjective Estimates Using Paired Comparisons“, a chart presents data suggesting that the described method of paired comparisons leads to more accurate judgments than “ad hoc estimates”, however, the article does not provide a reference to the study from which the data originates.
  • A 1991 study by Vicinanza et al., “Software-Effort Estimation: An Exploratory Study of Expert Performance“, is cited in support of the claim that experts are more accurate in relative estimation, vs. absolute. In fact, the study showed that a sample of five managers, shown data from past projects one at a time and asked to estimate their cost, were more accurate than estimates derived from the mechanical application of COCOMO.
  • In a 1998 study by Lederer and Prasad, “A Causal Model for Software Cost Estimating Error“, also cited on relative vs. absolute estimation, the words “relative” or “absolute” do not appear at all – the main finding, also on project-level rather than task-level estimates, is that “only one managerial practice – the use of the estimate in performance evaluations of software managers and professionals – presages greater accuracy”.

In summary, these studies which have for a few years now given rise to the claim that “research shows that people are better at relative than absolute estimation” do not in fact seem to square with that claim. This doesn’t entail that relative estimation doesn’t work – only that it is not proven.

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs. LEARN MORE >

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

Agile projects are iterative insofar as they intentionally allow for "repeating" software development activities, and for potentially "revisiting" the same work products (the phrase "planned rework" is sometimes used; refactoring is a good example).
Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.
In consultation with the customer or product owner, the team divides up the work to be done into functional increments called "user stories."
A sprint backlog is the subset of product backlog that a team targets to deliver during a sprint to accomplish the sprint goal and progress toward an outcome.
A sprint backlog is the subset of product backlog that a team targets to deliver during a sprint to accomplish the sprint goal and progress toward an outcome.
Collective code ownership is the explicit convention that every team member can make changes to any code file as necessary: either to complete a development task, to repair a defect, or to improve the code's overall structure.
An approach to estimation used by Agile teams. Each team member "plays" a card bearing a numerical value corresponding to a point estimation for a user story.

Help us keep the definitions updated

Ready to join Agile Alliance?

Unlock members-only access to online learning sessions, Agile resources, annual conference discounts, and more! And when you join, you’ll be supporting our member initiatives, regional events, and global community groups.

Privacy Preference Center

IMPORTANT: We have transitioned to a new membership platform. If you have not already done so, you will need to SET UP AN ACCOUNT on the new platform to establish your user profile. Your previous login credentials will not work until you do this set up.

When you see the login screen, choose “Set up Account” and follow the prompts to create your new account. You can choose to log in using your social credentials for either Google or Linkedin (recommended), or you can set up your account using an email address.