ian-deed

Estimates are one of the most important and most challenging parts of agile delivery. Knowing when and where to place teams and resources is vital to making the most of your time and your talent. Done well, reliable agile estimates can see even large, sprawling, and ever-changing projects come in on time and under budget.

Like many things in successful project management though, this is far easier said than done.

There are an array of cognitive biases, both optimistic and pessimistic, that lead us to put too much or too little time towards a task. Being aware of these biases is the first step to overcoming them in creating your estimates. The next is to bring on board the tools and strategies necessary to guard against them and improve communication in all future projects.

Our guide to the best agile estimation techniques can steer your teams towards project success with the right tools and techniques to help you to make better estimates to reign control of your software delivery.

Agile Project Management

The principles of agile project management are designed to create an iterative approach towards software engineering. Where older models were linear, relatively rigid, and designed for minimal change—agile is feedback oriented, responsive, and geared towards constantly changing requirements.

Good estimation techniques are key to success in this area. Defining how resources will be spent for the following weeks and months, agile estimates create the shape, goals, and duration of a project based on its stories.

Whether our goal is a minimal viable product for release, incremental improvement of software, or a major update of a popular package—there are some key principles to follow.

Keep It Simple

If there’s one axiom key to software development at every stage it’s ‘add simplicity’. Much like software, projects function at their best when designed with simplicity in mind.

Smaller Is Better

Related to simplicity, smaller units of work improve reliability, understanding, and accuracy. While increasing scale and complexity inevitably leads to trouble, smaller divisions of work leave less room for scope creep, fewer chances for things to go wrong, and are easier for teams to put in context.

Break Down Project Silos

One of the largest demands agile software development makes is for cross-functional teamsto work well together. In practice, this means both technical teams and non-technical stakeholders need to communicate well.

Even in mid-sized teams, maintaining open, accessible, and consistent communication can be a significant challenge. Good management techniques should break down silos of knowledge and share domain-specific information to improve performance.

Reflection and Adjustment

Agile is built around the idea of continuous adjustment and refinement in projects. For teams to improve their methods and approach they must be able to reflect on what is working well, what isn’t, and what they can change to make things better.

While reflecting on the state of an ongoing project isn’t a small challenge, it’s also one of agile development’s greatest assets—for teams who can use it.

Why Do Teams Create Agile Estimates?

Our management brain is an inherently flawed estimation tool. Cognitive biases lead us to underestimate tasks we can easily grasp and overestimate ones we have little information on. It’s easy for teams to become anchored on an initial estimate, even when it’s wrong. It’s even easier still to be left chasing time towards the end of a story.

Yet, despite being such a challenging discipline, agile estimates are critical to our projects. They define timescales, budgets, and resources for months at a time.

Employing some common and useful techniques can improve our agile estimates and overcome some of the pitfalls, biases, and errors that impact our estimation ability.

Early-stage Agile Estimation Techniques

The first step in refining project estimates is to create a rough draft initial outline to be refined later.

The primary goals of this stage may not necessarily be to land on a number that assigns hours or effort to tasks. The main goals of early-stage agile estimates are to improve the visibility, decision making, and risk management associated with a project’s tasks.

The result should be to gain an initial impression of a project’s stories that is shared across the team. These techniques should work to break down silos within a project, shrink stories down to a more manageable size, and create a list of stories by their scale and complexity.

1. T-shirt Sizing

A highly popular estimation tool for arriving at an excellent approximation for the size of a task.

T-shirt sizing assigns rough estimates to stories using t-shirt sizes as a guide to anchor to: XS, S, M, L, and XL. Team members choose what size a story is according to the amount of effort they feel will be necessary to implement it.

The key advantage of t-shirt sizing estimates is the ability for the technique to break down a difficult task into something that’s easily relatable, simple, and fun to do. It should allow you to grasp the scale of a project by the number of small, medium, and large stories that go into it and what XXL stories need to be broken down further to fit.

As a first-stage estimation tool, it’s an ideal starting point and well-suited to newly formed teams and very large backlogs.

2. Affinity Estimation

An agile estimation tool designed to make accurate estimates easier, affinity estimation techniques allow teams to work through excessively large product backlogs in a short amount of time. The concept behind affinity estimation lies in creating comparisons between stories rather than building an estimate from scratch.

Taking the first story from the stack, the product owner sets a ballpark estimate to begin. The next story is then compared to the first to decide whether it takes more time or less than our current one.

One key advantage of this method is in prompting discussion amongst teams about tasks and why team members believe it should rank higher or lower than others. Affinity estimation stands out for teams as all its discussion is done openly. While increasing visibility and awareness, a drawback of affinity estimation can be in some team members anchoring the estimates of others inadvertently.

The rapid speed at which this technique allows teams to assess stories makes it well-suited for handling large backlogs in a short period of time.

3. Dot Voting

An agile-first approach that builds on team’s familiar practices.

Dot-voting is already a key part of the retrospective for many agile teams. As an estimation technique, it’s a deceptively simple way for team members to express the amount of time and effort they expect stories to take.

For efficient dot voting, product owners should set up a story on a digital whiteboard. Dropbox, Google Jamboard, and Miro all have exceptionally strong products well-suited to this task.

Using the whiteboard, set a scale for the group using either abstract figures or the number of hours expected on a story. Users should then add the number of dots to the story according to the development effort they believe it will require.

The most interesting results happen where there’s a large split in the estimates of team members. Prompting further discussion and investigation—dot voting is a great way to help teams share perspectives and knowledge of the effort needed to complete a story.

One potential drawback of the technique, like affinity estimation, is the ability for early guesses or those by more senior developers to influence results. Finding a way to hide guesses until the votes are in is an ideal way to avoid anchoring and create better story estimates.

Dot voting works particularly well with well-established teams, mid-sized backlogs, and those that work closest together.

4. Maximum Allowable Size (mas)

A highly-useful way to sift through stories and find out which ones need breaking down into smaller and simpler sub-components.

MAS focuses on breaking down large and unwieldy epics into more manageable stories. It’s especially well-suited to sifting through exceptionally large backlogs to finding epics that need to be broken down before they can be actioned in sprints.

The first step to implementing MAS is to define a scale based on the number of hours a story will take. A maximum size of 16 hours is a good approximation for most agile tasks.

Going through the backlog with 16-hour tasks as a measuring tool, teams can vote on stories they believe will take more than the benchmark. These stories can then be broken down into multiple smaller stories until reaching a series of tasks that each takes less than 16 hours.

MAS is an exceptionally useful tool for tackling stubborn parts of the backlog that would otherwise take a long, long time to reach.

5. Big, Uncertain, Small

An estimation technique designed to tackle uncertainty head-on. Big, Uncertain, small may be the simplest technique available, but it serves as an ideal first pass over exceptionally large backlogs.

Teams work to categorise their stories into just three groups. Large stories, small stories, and those that require further information before action.

The key advantage of this technique is the ability it gives for teams to say ‘I don’t know’ when landing on a particular story or task. Big, Uncertain, small can provide visibility over stories that need more context or further discussion.

Most stories will need further filtering or a more refined scale later in the estimation process, but this tool is a great way to prompt discovery and investigation into a story.

Late-stage Agile Estimation Techniques

While early-stage estimation focuses on sharing context and information about stories on the backlog, late-stage estimation shifts its focus to accuracy and reliability to create concrete time estimates on a project.

Building on the filtering done by early passes, late-stage estimation techniques enable teams to put a number of hours of effort to a task with confidence and shared knowledge.

6. Sprint Poker

Part gamification technique, part agile estimation process—sprint poker aims to reduce cognitive bias amongst teams and create a more detailed estimation to work with.

The concept behind sprint poker lies in distributing a set of virtual numbered cards that correspond to the units of effort a story might take. After selecting a story from the backlog, team members play the card with the best guess estimate of what they believe the story will need.

If guesses are wildly different from each other then it’s likely more discussion is warranted amongst teams. Whether some team members know about some added complexity, tricky testing, or a shortcut to implementation—shared context will help everyone gain a more thorough grasp of the task.

If all guesses converge towards a common point then it’s very likely that the average guess is a good estimate of how long implementation will take.

The biggest advantage to sprint poker is that it prevents one team member from anchoring an estimate too high or too low. It’s a solution well suited to established, cohesive teams, and a prioritised project backlog.

7. Three-point Method

Three-point estimation is a tool for considering the best, worst, and most likely case scenario for a user story.

The concept behind the method is that a solid agile estimate lies somewhere between the best, worst, and most likely case scenario for a story. The average of these cases is very likely to provide a strong estimate to manage our projects.

One of the strongest advantages of the three-point method is in forcing a conversation about upcoming roadblocks and problems. Being pro-actively aware of these factors helps teams to guard against scenarios that come up during development.

To do this well, team members need to think about three values that go into every story:

• Optimistic value: How much effort will this task take if everything goes according to plan?
• Pessimistic value: How much effort will this take if you run into every blocker?
• Most likely value: What’s the most likely case for this task?

With a value given for the best, worst, and most likely scenarios you can compute an average estimate in one of two ways:

• A simple average of the three estimates: Optimistic value + Pessimistic value + Most likely value / 3
• A weighted average skewed towards the most likely scenario: Optimistic value + Pessimistic value + (Most likely value X 4) /6

Three-point estimates are a great way to ensure teams are aware and prepared for the potential challenges and pitfalls of upcoming sprints.

8. Relative Mass Evaluation (rme)

Sometimes labelled as the ordering protocol, Relative Mass Evaluation offers a compromise between precision and speed. In contrast to affinity estimation, RME considers all stories at once to generate an estimate using a wider perspective of the project.

Using a numbered scale, RME asks team members to place stories from the backlog along the scale according to the amount of effort required to go into them.

Like sprint poker, disagreement on story placement warrants the most interesting discussions on what goes into a story and the amount of time required. The biggest strength of RME is its ability to prompt open discussion on stories.

RME is well-suited to projects with a large number of individual stories to evaluate in a compressed period of time. It’s a technique that can be approached as an early-stage approximation or a late-stage estimation by adding more detail and discussion.

Estimation Techniques for Your Teams

Going through the processes of estimation with newly established teams is a lot like trying on new clothes for size. You’re most likely going to have to experiment with many options before finding an ideal fit.

Changing up your approach to choose different estimation techniques for different kinds of projects can make the whole process more interesting and engaging for team members. Each of the processes listed here answers different kinds of questions about your project and its stores. Each technique used will prompt different kinds of discussion within your teams.

Knowing which tool to use, when, and how to use them can take a lot of skill and practice. Being overly optimistic with estimates is typically the most counter-productive strategy, but being overly pessimistic rarely helps much either.

Iteration, retrospectives, and continual refinement are as key to agile estimation success as they are to the success of your teams and their organisation.