Relative Estimation
Relative Estimation
Most commonly, agile teams use relative estimation to size the work they need to do - that is they estimate the size of a backlog item relative to other backlog items. Relative estimation is based on having a sufficient understanding of a backlog item so that its scale, complexity, risk and many other factors can be assessed against those of similar, related or recently completed backlog items.
In A Nutshell
When we work with a backlog, delivering value as rapidly as we can, we have little time to spend estimating and planning our work. In any case small batches of work serve to limit the value of undertaking detailed estimation and planning. The Agile approach to these topics is radically different from traditional project planning.
Traditional approaches emphasise producing absolute estimates for each and every requirement to be delivered. These can be finger in the air guesses - with outcomes probably less accurate than from relative estimation. Or they can be algorithmically based - including approaches as complex as the use of function points. There are always question marks about the efficacy of such approaches because they are so dependent on the quality of requirements used as input.
Combining the potential lack of efficacy of absolute estimation with our desire to streamline planning as much as possible, we need a simpler, more proportionate approach to estimate our agile work. Relative estimation asks only that we can compare backlog items to each other and put them in a sequence based on “size”.
Some approaches assign labels to different categories of size. The categories can be numeric - story points, for example. Or they can be descriptive - T-shirt sizing or Animal sizing.
The skill of the team is the ability to sensibly compare different backlog items. This requires experience of the domain they are working in and that the backlog items be of sufficient quality to support comparison. New teams and teams working in new domains will find relative estimation challenging because of their lack of domain experience. Teams who are not well disciplined in refining their backlog items will similarly struggle to achieve a good relative sequence. The INVEST criteria are useful in helping us to understand the quality of our backlog items.
Some highly disciplined teams can refine backlog items with sufficient rigour to effectively make all items roughly the same size. For these teams estimation beyond counting the number of backlog items becomes irrelevant. This is popularly referred to using the hashtag #noestimates.
At the other end of the spectrum, new teams may also find item counting most effective. If a team is unable to size accurately, then counting items will be as good an estimation strategy as any other. The team may still choose to dedicate effort to estimation because the conversations they have help them better understand the backlog item and because they the will learn to size more accurately as they gain experience.
When we undertake relative estimation our goal is not the traditional estimation goal of “how much will all this cost” or “how long will it take”? Rather our goal is to ensure that we do not overcommit ourselves - that our plan for delivery in our next planning horizon is realistic.
Sources
INVEST
A set of criteria to help assess the quality of backlog items.
anAgileMind INVEST page
We have observed that some teams become over committed to the use of the INVEST criteria so that they become a form of contractual behaviour. This may be expressed as “we will not accept any story that we assess does not meet the INVEST criteria”.
Story Points
The use of numbers drawn from the Fibonacci series to label size categories
an article from Mountain Goat software about story points
We have observed that inexperienced teams can get obsessed by the meaning of the numeric value they assign. It is important to stress that the number is just a label and has no quantitative meaning.
Some teams try to use too many different size categories. We have observed 3 categories plus a bin are normally sufficient. The bin is used for items that were thought to be estimable but turn out not to be.
T-Shirt Sizing
The use of labels such as “S”, “M” and “L” to label size categories
KnowledgeHut article on T-shirt sizing
Some teams try to use too many size categories. We have observed that 3 categories plus a bin are normally sufficient. The bin is used for items that were thought to be estimable but turn out not to be.
#NoEstimates
Ensuring that we estimate in the simplest and most effective way possible that helps us to avoid over committing without wasting the time and effort of the team.
Techbeacon article on the origins and nuances of the #noestimates debate
As the article makes clear, we have observed that the debate can become very polarised. We support the position of Zuill who takes a pragmatic approach that can be summed up as “all estimates are wrong, but some are worth having”.
Related Practices
Teams plan work to fill their short-term planning horizon. With a clear understanding of current priorities and the capacity of the team, work items are chosen to satisfy the forthcoming delivery goals. The team elaborates the plan as necessary to ensure that there is a shared understanding of the work that is required.
Product Backlog Refinement is a Scrum activity that is performed on the Product Backlog. The scrum guide defines Product Backlog Refinement as the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Product Backlog is the vehicle by which needs are turned into requirements and requirements are turned into operational features in our product. It is a prioritised list of the work that the team currently intends to deliver in the next period of time. The less imminent a feature is, the less well it will be defined.
Sprint Planning is a Scrum event that is held before the start of the sprint to establish the scope and priorities of the coming sprint. Its purpose is for the whole team to establish an agreed sprint goal based on the Product Owner’s view of the value that can be created for the customer. To establish a scope of backlog items that can be got to done. For each backlog item the team decides how done will be achieved.
Related Articles
Relative estimation is a simple concept, but one that causes all sorts of problems for new teams and for experienced agile practitioners. This article examines some of the reasons behind the confusion and suggests a new, clearer way of thinking about the process of relative estimation. This new pattern makes a very clear break from more traditional estimating techniques.