4 Agile estimation techniques and their effect on velocity

It’s crucial for stakeholders to have a good idea of how long a project will take. The first encounter with Agile might raise concerns of uncertainty, but there are ways to address it—which is good news! Estimation techniques are directly related to the velocity of your team, so let’s define that first.

In this article, we’ll cover the most commonly used velocity estimation techniques in Agile ceremonies, such as Planning Poker, Story Points, and more.

1. Fibonacci Sequence for Story Point Estimation

This is almost the backbone of estimation in agile.

The Fibonacci Sequence is a sequence of numbers where each number is the sum of the previous two numbers.

The first two numbers in the sequence are both 1, and all subsequent numbers are calculated by adding the previous two numbers: 1, 1, 2, 3, 5, 8, 13, 21, and so on.

The idea is to approximate how many times the complexity changes between tasks. What makes the sequence perfect for agile estimation is the fact that the numbers go up by about 1.6x. It’s not quite double, which forces teams to be more deliberate in their estimation. And, let’s face it – tasks rarely go up in complexity in a perfectly linear way. It’s more likely that you’ll encounter a user story with a Fibonacci complexity of “2” and a “3”, than a “2” and a “4”.

Usually, the later numbers in the sequence are simplified – 21 is often followed by 40, then 60, and then 120.

But quite often the estimation stops around 40, or even 21. Let’s face it, there aren’t many software projects where something is realistically 40 times as complex as a different task.

2. Planning Poker

In this technique, each team member receives a set of cards that contain numbers that the team agreed to use as their estimate. Usually, it would be the modified Fibonacci sequence from the previous chapter. You can purchase physical cards and these rarely go beyond “21”. For some of them, it ends at an even “20”.

Next, the product owner reads a product backlog item and briefly discusses it with the team.

Once each team member decided on an estimate, they pull that card out of their hand in a way that no one else can see it. When everyone has picked an estimate the cards are revealed all at the same time.

If everyone is holding the same number… hooray! We agree on an estimate and proceed.

But if the numbers are different, the team tries to align their understanding of the task and estimate again until most of them hit the same number.

Planning Poker establishes mutual understanding

While this varies, most teams won’t be perfectly aligned with their estimates. This makes Planning Poker the perfect vehicle for team alignment. Discussing tasks is a great way for the team to learn and discover new perspectives, but you might’ve guessed that it’s time-consuming. As such, Planning Poker is recommended for smaller backlogs.

Another important outcome is improving the way your team communicates requirements. If there’s a pattern of estimate mismatch, it might be a red flag for how you write down your tasks.

We like the principle of “walk-up simple”, where virtually anyone in the business (or ideally, even a random person from the street) understands what they need to do to complete a specific task.

3. T-shirt sizing in project management

A less formal and more creative type of estimation where items are estimated in standard t-shirt sizes (XS, S, M, L, XL… )

Agile estimation is abstract as it is but this takes it to the next level. You’re not even using numeric values. T-shirt size estimates mean that the concept of velocity is almost gone, at least as a single value. We can no longer say that the team velocity is 70 points or 100 points.

Instead, we still can aggregate the data and say that in one sprint the team can deliver 1 XL task, 3 M tasks and 8 S tasks.

It’s a great technique for teams that are new to agile estimations and are having a hard time estimating time/points to complete a story. It’s also great for design estimates. You can’t exactly use comparative estimation for designs, but you can probably gauge whether designing a certain feature is a large or a small task.

4. Complexity Buckets

Complexity Buckets have been used in software development since the 1980s and it’s still one of the most popular methods.

The technique consists of three steps:

1. The first step is to divide the entire project into smaller tasks and assign them to different categories depending on their complexity level. These categories are called “buckets” or “levels”. There are five levels: Very Simple, Simple, Moderate, Difficult and Complex.
2. The second step is to estimate how many hours each task will take and what level of expertise will be required for its completion. This can be done by using a simple questionnaire that includes questions about the difficulty of specific tasks (e.g., how complicated is it?) as well as estimates for how many hours each task will take (e.g., how many hours do you think it will take?)
3. The third step is to calculate an average value based on all answers provided by employees who participated in this estimation process so that everyone has a chance to contribute their knowledge about what needs to be done for this project to succeed without any problems whatsoever.

Which agile estimation technique should you choose?

Using different estimation techniques can have a large impact on the velocity of an agile team.

The most common technique is planning poker. It’s approachable, but it’s also not precise and doesn’t scale well. The other two techniques, story points and t-shirt sizes require more effort but they give you a more specific estimate than planning poker does.

Ultimately, the right choice for your team depends on what you’re trying to accomplish—do you need quick estimates or precise ones?

Be aware that story point estimates are best used for sprint planning. Bucket systems, dot planning, and t-shirt sizing are better for a roadmap and release planning.

Have you ever worked with or for an Agile agency? Let me know about your experiences in the comments.