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

The acronym INVEST stands for a set of criteria used to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limit work in progress (WIP) and stop starting and start finishing.
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).
Continuous deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production.

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.