Agile estimation techniques: a guide

Agile estimation – predicting the level of effort required to complete a development task – is a notoriously unforgiving chore. There are so many variables and downright unknowns in most software projects that making data-driven, reasonably accurate project estimates can seem virtually impossible.

Despite the headwinds, estimation is a fundamental and unavoidable element of software project management. Development teams rely on estimates to build achievable schedules and prioritize work, product owners rely on estimates to build product roadmaps, and management relies on estimates to set and track budgets.

In agile, we approach software estimation within the same philosophical framework we use to attack other project management activities. These agile estimation techniques are a vital part of successful agile project management.

Agile estimation is based on simple, easily determined measures that are iterated and refined throughout the software development lifecycle. The results of this process are estimates that are often more accurate and almost always more useful than those produced by other approaches. In this post, we’ll dive deeper into the concepts and techniques of agile estimation and how to get started with them. Then, we’ll show you how you can get started putting these ideas to work with Zenhub.

What is agile estimation?

In traditional software project management, estimates are based on the question, “How long will it take?”

In agile, estimates are based on the question, “How big of an effort is it?”

While at first glance, the difference in approaches might seem subtle and even a little arbitrary, this reframing of the question from time to size turns out to be a real game changer, enabling other factors to be considered in estimates like difficulty, resources, and dependencies.

Agile estimation scales and story points

Before we get into agile estimation techniques, lets talk about story points and agile estimation scales – the foundation of most of the agile estimation techniques you’ll read about.

In agile, “story points” are numerical representations of effort. Using story points, each estimated story (unit of work or “issue”) is assigned a value such as 2, 3, or 5. As mentioned above, this is not referring to measures of time (i.e. a “2” is not 2 hours or two days) – this is based on how “big” of an effort the work entails. Story points are based on relative value – a value of 3 is meaningless by itself. All we know about a 3 is that it’s larger than work considered a 2 and is smaller than a 5.

Story point values are selected from an “estimation scale.” One of the most common scales (and the one used in Zenhub by default), is called the Fibonacci scale: 1, 2, 3, 5, 8, 13, 21, 40. This scale is non-linear, with the gaps between numbers increasing as the numbers get larger.

The increasing gaps in the Fibonacci scale are useful because as stories get larger, there are more uncertainties and estimation becomes more difficult and the issue is considered too large to estimate. These stories would be assigned 40 story points and be flagged to be broken down into smaller stories somewhere down the line.

Agile estimation techniques and sizing methods

With some basic agile estimation concepts under our belts, we can turn our attention to how these concepts are put to use. There are a handful of tried-and-true techniques that agile teams have developed over the years. Here are some of the most popular agile sizing methods and estimation techniques:

1. The T-shirt sizing agile technique

Consider the quintessential agile unit of measure: T-shirt size. Most of us could look at a T-shirt and make a good guess as to whether it’s small, medium, or large. Even if we were given a big pile of T-shirts and asked to sort them by size, we would probably succeed at that task too. Just like we’re all pretty good at ranking T-shirts by their relative sizes, development teams are pretty good at ranking stories by their relative sizes.

In the same way we’d have a hard time guessing the exact width of a T-shirt, it can be difficult for development teams to guess exactly how long a task will take. Instead, just like how we’d find it easier to rank T-shirts by their sizes, teams are better at ranking stories and work by relative size.

The t-shirt method is just a method of visualizing how large a workload is in relative terms. Teams using this method can choose to have corresponding story point values for tracking and reporting purposes. For example, a 3 is a small, a 5 is a medium, an 8 is large, anything above is XL and anything below is considered XS. For teams not interested in agile reporting, using actual sizes like small, medium and large can be an actual scale that is used for this estimation technique – but this isn’t common for most agile teams.

2. Planning poker

Planning Poker is perhaps the most popular estimation technique, and most agile teams use some variation of the approach. Planning Poker is an exercise that involves the entire development team. Traditionally, each member has a deck of cards that shows the numbers of the story point scale. As stories are reviewed, each team member silently arrives at a score and then all team members reveal their selected card at the same time.

The team then discusses the scoring, and members contribute their rationale for the score they awarded. After discussion, the team again votes with their cards. The goal, and typical outcome, is to converge upon a single, agreed-upon score within a few rounds.

With remote and asynchronous work being the norm now, this old-fashioned estimation technique is not possible for most teams. Because of this, many teams are now taking to online agile planning poker tools like Zenhub’s planning poker feature to make agile estimation faster and more accessible.

3. Affinity grouping

Affinity Grouping is an alternate method to Planning Poker in which team members group items into tiers based on relative size. The basic process is usually carried out with sticky notes on a board. The notes are arranged with smaller items going to the left and larger items to the right.

The backlog is taken one item at a time. The item is discussed in terms of how it compares to the size of items already on the board, and then placed on the board accordingly. The items arrange somewhat naturally into columns which become affinity groups. Story points are assigned based on the story’s affinity group.

4. Dot voting

This is a simple method of organizing your product backlog items one is fairly simple but only for estimating small user stories. Every person gets a definite number of dots (4-5) that can be used to vote on user stories. You can use an online tool while remote or a whiteboard when in the office.

The more dots, the more time and effort needed to complete the item. In the end, you should have a list of items sorted by their priority.

5. The bucket system

What about large numbers of user stories?

The Bucket System can be even more efficient and quick than other methods in estimating task complexity.

Each person will add tasks to one of the available buckets based on their relative urgency and priority. After every team member has divided the tasks, these will be reviewed together to reach a consensus.

Here’s a detailed look at the process in action:

6. The three-point method

Ever been working on a project you thought was going to take a short time but ended up taking twice as long as expected? The three-point method aims to prevent this from happening and facilitate more accurate agile estimation by averaging 3 different story point estimates.

The 3 different estimates vary in optimism:

Estimate #1 – Optimistic: In a perfect world, what’s the most ambitious estimate for this story?

Estimate #2 – Pestimistic: If many unanticipated blockers come up, what is the most conservative estimate for this story?

Estimate #3 – Practical: What is the most likely estimate for this story?

Once you’ve determined your estimate for each of the above categories, you can go ahead and average the number to get your estimate. You can also place more weight on categories you think are more important, such as weighing the Pessimistic option more if you’re working with important stakeholders and want to be more conservative.

Validating and refining agile estimations

Even with great estimation techniques, teams can still need help with sizing. If your team is routinely missing the mark – saying that hard jobs will be easy or easy jobs will be hard – then more proactive steps are in order.

Retrospectives are an agile best practice and the perfect time to review estimation performance and discuss causes of estimation errors. Ideally, your team is doing a retrospective after every sprint. Since story point estimation is based on relative sizing, it can be helpful to compare like-to-like in retrospectives. A common approach is to select two or three completed stories with the same point value and reflect on whether these stories did end up taking similar amounts of effort. If not, the team can try to determine what might’ve contributed to this discrepancy. Were the stories well-defined? Did the team consider the effort of related tasks, such as testing? Is the team being too optimistic about certain types of work? If your team routinely works through difficult questions like these, estimation should become more consistent and reliable over time.

Agile estimation in Zenhub

Zenhub makes it easy to apply story points, velocity, and other agile concepts to your estimation and planning activities.

Story points can be assigned directly to any Issue in the backlog. When you’re viewing an Issue, project estimation is available to you in the sidebar, where you can select the story point value from a dropdown. Zenhub uses a Fibonacci estimation scale by default, but it’s easy to customize the scale if desired. You can also do planning poker right in Zenhub and request asynchronous estimates from team members. Zenhub will automatically apply estimates when the team agrees. This makes agile estimation much faster, enabling you to only meet about issues your team can’t agree on. This helped our internal team reduce their backlog refinements meetings from 1.5 hours to just 10 minutes! Learn more about planning poker in Zenhub.

Estimating your Issues also allows you to gain insights using our suite of Reports. Zenhub’s Burndown Charts, for example, pull in all the estimated stories from a sprint to give you a visual representation of the in-progress sprint. You can see what has been completed and what remains unfinished, and you can assess how the team performs against what was originally planned.

Once you have a few closed sprints, Zenhub automatically builds a Velocity Chart, allowing you to use historical velocity to predict future trends. These reports show the last seven completed sprints. The Velocity Chart allows you to quickly see how consistently the team has been performing and to easily drill down into sprint performance in greater detail.

Zenhub’s default settings and automatic integrations make it easy to jump in and use agile estimation for your GitHub projects.

Agile estimation best practices

Before you leave to start estimating, we’ll leave you with some best practices:

Agile estimation should judiciously apply just the right amount of effort needed to get a good enough result. Try to avoid overthinking the estimate or spending too much time diving into technical details. To learn more about getting started with software estimating in Zenhub, download our free ebook: Better Software & Stronger Teams.