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.
Velocity is the amount of work that can be done in an iteration. It’s used to track how much work you’re getting done, and to estimate the team’s capability going forward.
In this article, we’ll cover the most commonly used velocity estimation techniques in Agile ceremonies, such as Planning Poker, Story Points, and more.
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.
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.
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.
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.
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:
Have you participated in poor daily standups? What was the number one reason that stood out as inefficient? Share it with our readers in the comments and someone from our team will get back to you with feedback and ideas on how to improve it.
And for those commenting for the first time, don’t forget to grab your FREE PDF along the way!
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.
Do your daily “status report” meetings suck? We’ve all been there. So here’s our gift to you – immediate access to a PDF that will improve them.
Originally published Jun 05, 2022 4:53:00 PM, updated June 23 2023.