Agile Estimation Methods in a Nutshell

What’s the best Agile estimation technique?

People from all over the world often ask me this question. The question itself doesn’t bug me, but the misunderstandings of estimations do. If you are searching for a perfect way to predict effort, I am afraid you will only be disappointed.

In a complex system, estimations will always be inaccurate.

But wait a minute, if estimations are inherently inaccurate, what’s their point? You may think estimates enable you to create a rock-solid plan. Perhaps you use estimates to develop an extensive and precise Gantt Chart. Many Project Managers used to do that, and inevitably one day, they would come to work and say, “Either we cut scope, or we miss the deadline.”

Lesson: Don’t use estimations to make promises; they won’t make your teams 100% predictable

In my perspective, estimates help us understand our uncertainty level. An excellent method will develop a shared understanding across the team, ultimately speeding up the results.

In this post I will share the most common Agile estimation techniques and explore their advantages and disadvantages. After reading this piece, you should have a better understanding of which technique to use in different situations.

Estimation Escale

With Agile frameworks, the estimation often utilizes complexity instead of effort. The reason is simple: estimating in absolute time is unreliable. Software development has too many variables, and the relation to each other is unpredictable.

You may have an idea of how much effort you need to implement something, but you will only have assurance after you get your hands dirty. Also, developers have different levels of experience and expertise, which means the required time to develop a specific task will vary depending on who was working on it.

The most common complexity scale is Story Points, which follows the Fibonacci sequence . The idea is simple: the more complex it gets, the more uncertainty you have. The original series goes: 1,1,2,3,5,8,13,21,34,55,89… but Story Points use a modified version to facilitate understanding: 1,2,3,5,8,13,20,40,100.

To learn more, you can read this blog post by Mike Cohn.

Planning Poker Estimation Technique

The most common agile estimation technique

With a decade of experience under my belt, I can confidently say Planning Poker is the most common agile estimation method among Agile teams. The beauty lies in its simplicity: in less than five minutes, anyone can understand how it works. In a nutshell, it’s like this:

1. The Product Owner or equivalent takes an item from the Product Backlog, reads it, and explains it.
2. Team members ask questions to ensure understanding, and once they are ready, they can estimate.
3. Every team member is involved in the implementation estimates (Scrum Master and Product Owners do not estimate).
4. Every member reveals their estimates in Story Points at the same time.
5. The extremes explain the reasoning behind their choice. For example, in a team of five people, say one person estimated a 2, another 13, and all the others gave a 5. Whoever voted 2 and 13 will share their reasoning.
6. After the extremes have spoken, another round takes place.
7. The estimation ends when the team reaches a consensus.

I’ve experienced both sides of the coin with Planning Poker, it can generate a lot of searching and can drain all of your energy. Let me help you benefit from it.

Planning Poker Disadvantages

• It can easily be time-consuming.
• Teams can get stuck with questions and not move on until they clarify all doubts.
• If you strive for consensus, be ready for too many rounds (a minimum of 3).

Planning Poker Advantages

• It helps the team learn from different perspectives.
• It’s dynamic - everyone participates.
• Implementation is straightforward.

My recommendations

I’ve been using Planning Poker until now, with some alterations:

• Timebox for questions after the Product Owner explains the item. It takes 5 minutes.
• After the extremes share their perspectives, I opt for democracy instead of consensus.
• I break highly complex items (generally anything bigger than 13) into smaller ones. This increases certainty and speeds up the team.

This video may help you visualize this agile estimation technique in practice:

‍

‍

Magic Game Estimation

Sometimes you may want to estimate a chunk of backlog items in a short period. Suppose you have fifty things you want to get estimated; opting for Planning Poker may take you at least four hours. That’s when Magic Estimation comes in handy: depending on your speed, you can estimate up to sixty stories an hour!

Here is how it works:

Preparation: create a digital board or a wall with your estimate scale. Prepare a list of cards with the items you want to estimate.

The event will run like this:

1. A developer picks one card, reads aloud, and silently positions it under the chosen estimate.
2. The next developer can either pick a new card and repeat the first step, or pick an estimate card and re-estimate.
3. The game ends once there are no more items to estimate, and the team members decide to stop re-estimating.

Magic Game Disadvantages

• No discussion occurs among team members.
• The Product Owner becomes an observer.
• No shared understanding is created.

Magic Game Advantages

• It helps you estimate several cards in a short time.
• It makes you feel the team is uncertain (cards re-estimated).

My recommendations

I’ve used the Magic Estimation several times, and I had a feeling something was missing. For me, the silence and lack of interaction left me insecure about whether our time was well invested or wasted. That’s why I made some adaptations to the game, and they work pretty well for me:

• After reading a card, the person can ask the Product Owner a question. The answer should take no more than 30 seconds.
• When estimating, the person can say their reason in one sentence.

With these changes, I have the confidence that the team benefited from different perspectives. We could manage around 30 items per hour instead of 60, but that was already good enough for me. Collaboration is more important to me than speed.

You can learn more about this technique from this video.

T-Shirt Size Technique

Unlike the previous techniques, T-Shirt Size uses absolute time as a scale. It’s a standard method among agencies, as their clients often need clarity on investment before starting collaboration. It can vary according to the needs; you can use hours, days, weeks, or even months, but the main point is to have an idea of an absolute time range.

The use of T-Shirt Size is simple. You start with a range, and it doubles for the next one. Let me give you an example:

• S: from 1 to 2 days.
• M: from 2 to 4 days.
• L: from 4 to 8 days.
• XL: from 8 to 16 days.

You don’t need to double the estimate for the next size. You can define the range you want. Still, I recommend you double it because the more time you need, the less certainty you have.

I am particularly against this agile estimation technique as it often creates a false impression of time commitment, and people inevitably create false expectations. Also, it doesn’t help achieve a shared understanding among team members. T-Shirt Size is more related to traditional project management than Agile.

If you opt to use this technique, ensure your stakeholders understand that estimations are different from commitment. Re-estimate if needed, and communicate with your stakeholders to avoid confusion.

“To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.” —  Chinese proverb

#NoEstimates

Given all the complexities behind estimates and false expectations as a side effect, Agile practitioners challenge the use of estimates altogether. The question is, why would you invest time estimating something when you could invest your energy in solving it? That’s how #NoEstimates came to be.

The idea behind it is straightforward - you don’t estimate anything in your Product Backlog; you only ask one question: does it fit a Sprint? When you get a no for an answer, you break the item into a smaller one. Only items that fit a Sprint can be part of your Sprint Planning.

When I first heard about #NoEstimates, I was skeptical. But before reaching any conclusions, I decided to try it out. After two months of using it, I could understand how it works. And I ultimately opt not to use it anymore. Let me share my perspectives with you.

#NoEstimates Disadvantages

• The team misses the chance for gaining different perspectives.
• It’s hard to plan a Sprint when all you have is “yes, it fits” or “no, it doesn’t fit.”
• After the estimation, the problem may still be unclear to team members.

#NoEstimates Advantages

• The team saves at least two hours per Sprint by not doing estimates.
• Developers don’t get stressed by providing estimates they don’t care about.

You can learn more about #NoEstimates with this article.

Final Thoughts

After years of experimenting with different agile estimation techniques, I honestly don’t care about numbers. What matters to me is helping the team understand the problem and its constraints.

I use estimation to yield learning with the teams I work with. I don’t expect any technique to give me predictability or anything beyond understanding. Also, if it takes too long to estimate, it’s most probably a misuse of the method you are applying.