ALM #050: How to Plan Sprints and Roadmaps with Agile Estimation Techniques

A Practical Guide to Agile Estimation for Engineering Managers

In 2015, I had an interesting conversation with a developer about agile estimation, specifically how and if story points would translate into hours.

At the time, his team could complete around 80 points every sprint. The obvious thought that popped into my head was: two-week sprints, 40 hours per week, 1 point per hour.

The moment I made this correlation, it was like I had unleashed the spawn of the devil himself.

Note to self, if you’re talking to a developer currently working in the story point system, do not, I repeat, DO NOT, try to make any correlation between those points and hours.

This might sound a bit confusing for those with no idea what I’m talking about, so let’s try to break down the idea behind story points and relative estimation techniques.

Back in the early 2000s, several Agile methodologies appeared as a way to save us from the dreadful Waterfall.

For the dinosaurs amongst us that still recall those Waterfall projects, I’m sure you remember those long strenuous stages that the project would have to go through without any feedback or the uncertainty of if what we delivered to the client was still what they wanted.

Agile came and changed this. We started having quicker turnarounds and quicker testing loops where feedback was constant. With Agile came flexibility and the guarantee that no single developer is the same as another.

If you were to estimate purely in hours, you would either need to overestimate every task, or you would have to know beforehand who would do the task because a Senior Developer will take a different amount of time than a Junior Developer.

The idea behind relative estimation techniques is to dissipate these differences and allow for shared knowledge and shared task estimation.

Let’s look into four different relative estimation techniques, and then I’ll explain how we use these four techniques in conjunction.

Relative Estimation

T-Shirt Sizing

Starting with the most simple one, the idea behind T-Shirt sizing is to assign larger blocks of work (projects or initiatives) to Small, Medium or Large.

To make this work, the first step is to be very clear about what each t-shirt size relates to.

For example, you can have the following correlation between t-shirt sizing and sprints:

• S - less than one sprint

• M - less than a month

• L - less than three months

Or, instead of using time as the metric, you can base your t-shirt sizing on past tasks:

• S - add observability metrics to a service

• M - create a brand new API

• L - upgrade and propagate a new version of Kubernetes

Adapt T-Shirt Sizing to your reality by adding sizes like XS (Extra-Small) or XL (Extra-Large).

This method is an excellent way of removing the fear bias of attaching a timeframe to an initiative.

Affinity Estimation

Moving to a collaborative approach, you can do affinity estimation by grouping tasks of similar complexity or effort.

The best way to do this is to create a card for every initiative (physical or virtual), and each team member moves the cards around, grouping together those that should take a similar effort or be of the same complexity.

You do this several times until the whole group reaches a consensus.

One of the most significant advantages of this method is that everyone should have a deep understanding of those initiatives.

Planning Poker

It’s irrelevant if you’ve led teams for one month or ten years. I’m sure you already witnessed estimating sessions where you hear some voices more than others. This process should not be biased and instead promote collaboration.

A relaxed, fun way of promoting a healthy estimating experience, you can have your team play Planning Poker using cards (or apps). Each individual shares their estimate and then proceeds to a discussion. In my past experiences, you would accept the majority result if the difference was just one level to speed up the process.

Anything above that, you would stop and discuss the reasoning behind the estimation and reach a consensus.

Story Points

And then, we reach Story Points, probably the most used relative estimation technique by modern Engineering teams.

One of the main advantages of this method, as it moves away from an hour-based estimate, is that it considers the effort, the complexity and the unknown behind each task.

• Effort - The amount of work that this task requires.

• Complexity - How difficult the task is.

• Unknowns - How unclear the task is or how many risks it carries.

Usually, teams use the Fibonacci sequence as a standard scale for story points. But why Fibonacci? A couple of reasons:

• Growing intervals - As the Fibonacci sequence grows, the more significant the separation between the numbers is. The larger the estimate, the lower the accuracy of this estimation.

• Simplicity - It’s a straightforward method to use and understand.

• Relative - The nature of the Fibonacci is that each number is the correlation between the ones that precede it. This way, there is a relation between each value and in a way, a similar relationship exists between tasks.

And one of the exciting things about story points is that each team has their own way of estimating, assigning a value to a specific task based on previous tasks, previous experiences, the stability and the seniority and familiarity of the team.

How to use multiple relative estimation techniques?

So now you might wonder how to use these techniques in the real world:

• Start by using T-Shirt Sizing to estimate your initiatives. This will give you a lower granularity but will help you have a ballpark figure of the complexity and effort of your initiative.

• Along with T-Shirt Sizing, use Affinity Estimating to have a clearer idea of your future initiative backlog. This will be useful when you're creating a first draft of your roadmap.

• For the stories and tasks that deliver your initiatives, use Story Points and Planning Poker to align the estimates for your tasks. You can then use reports like Sprint Velocity Charts to understand your team's performance.

How about your team? What do you use? Hours? Story points? Drop me a message on Twitter!

I’ll see you next week 🫡