My recipe for effective task estimation

In my experience as software engineer, I've been mostly working by planning in pretty much static time periods, most commonly 2 weeks. Planning for these "sprints" meant deciding on the tasks we were going to work on and get done in the following 2 weeks.

At some point, teams ended up estimating the tasks, giving them some kind of size, in order to improve the confidence in their plans. Most of the time, we did it using Story Points, with a Fibonacci Sequence, of 1, 2, 3, 5, 8, 13 or 21 Story Points.

But while this was a common practice in the teams I worked in, not always we did use these effectively. Not only that, I saw teams dismissing the importance of a good estimation in moving with confidence into a new "sprint".

Below I'm collecting a script for estimation meetings that has worked for me over the years. Keep reading after for some pitfalls that I witnessed affecting the quality of the estimations.

Disclaimers:

• I'm using "sprint" in quotation marks to avoid discussing whether this is true agile and any of its flavors, but rather focusing on the learnings from my experience.
• This post is mostly relevant for those teams that don't need to commit to a time. If you do need to commit to a time, maybe some of the script below is relevant to uncover hidden complexities in your work, but you still need to translate complexity to time afterwards.

Estimations' meeting script

First of all, make sure you have a list of tasks to be estimated. Go from the top to the bottom of the backlog, in order.

Second, make sure it's clear to everyone what a 1 Story Point task looks like. Examples are often useful.

1. Read the top most task out loud. This is ideally done by the engineers with most context about the task. Provide any relevant context missing from the task description
2. Ask "Are there any more questions about this task?"
3. Ask "Is everyone ready to estimate?"
4. Give a count of e.g., 3 so that everyone gives their estimation at the same time, see Planning Poker
5. If there's consensus, move on and go back to step 1 with the next task
6. If there's no consensus, ask those with the higher and lower estimations to explain where they see the extra complexity or the lack of it
7. Allow discussion to happen but moderate it. Objective is to discuss complexity, where it can be hiding or how to simplify it. It's a good opportunity to highlight knowledge gaps
8. When done, ask if the team is ready to estimate again
9. Give a count of 3 like in step 4
10. If there's no consensus ask for disagreement and commitment on an estimation and move on to the next task

In my experience, these meetings were some of the most relevant for our day-to-day engineering work.

Team dynamics will also be very much in display here. As a leader, there are great opportunities here for you to shape them.

Common Pitfalls in Software Task Estimations

If you’re already conducting estimation meetings, the script above might offer ideas on improving them. However, beware of the common pitfalls below that often lead teams astray.

Misunderstanding the Purpose of Estimations

Estimates should help uncover complexity and increase confidence in planning, not just produce a number. Some common pitfalls here include:

• Expecting perfect estimations - no estimation will ever be 100% accurate and analysis or discussion to perfect an estimation will usually have increasingly diminishing returns.
• Estimating just for the sake of assigning numbers - if this is happening, you might as well use a random number generator! Instead, treat the process as an opportunity to think critically about potential challenges
• Forgetting that estimation is about planning, not prediction - paraphrasing Churchill: “Estimates are of little importance, but estimating is essential.”

Poor Execution of Estimation Meetings

Even when teams understand the purpose, execution mistakes can still cause problems:

• Not involving enough perspectives - every engineer, from junior developers to those from other platforms, can provide valuable insights. Diverse perspectives help uncover hidden complexities. Ideally, every engineer contributing to the sprint should be present
• Estimating in isolation - collaborative estimation leads to better understanding and more accurate assessments. If a task is so straightforward that you can estimate it alone, you might be better off just doing it
• Over-discussing when there’s already consensus - move on, unless there's important detail you forgot to mention, chances are that whatever is discussed then will only impact the estimation by 10% or less

Estimating the Wrong Things at the Wrong Time

Knowing when and when not to estimate is crucial:

• Don’t estimate if you don’t need to - if priorities are crystal clear and the team is focused, estimation might be unnecessary overhead. You can also try and control the task size instead and measure throughput
• Don't estimate too late - if a task has to be done no matter the estimation, then either you don't need to estimate or the estimate came too late. Consider giving rough sizes earlier with a different scale, e.g. shirt sizes
• Only estimate when a task is ready - dependencies should be mapped out and accounted for; otherwise, the estimate may change significantly later. If a task isn’t ready, improve it by adding missing details
• Use “spikes” for uncertain tasks - if complexity is unclear, declare a task a spike rather than forcing an estimate

Issues with Story Points and Complexity

Story Points should be treated as categories of complexity, not as exact numerical values:

• Avoid arbitrarily large estimates - set a maximum Story Point value; beyond that, tasks must be broken down
• Large tasks skew estimation accuracy - a sprint with six 5-point tasks is harder to predict than one with thirty 1-point tasks. In my experience, attempting to break a 5-point task usually left us with two 3-point tasks, which demonstrates the hidden complexities in bigger tasks
• Story Points are not time estimates - they represent complexity, effort, and uncertainty, not hours or days. Story points are usually a more abstract concept that allows for more sincere conversations about complexity

A piece in a larger process

Estimations are a part in a bigger process and can affect the quality of the downstream activities. It's equally important to keep in mind how the activities earlier relate to the estimations and influence their quality.

Estimations can be affected by the level of uncertainty a team is comfortable with; how much ahead from development the product and design goes; how much experience a team has in a certain tech stack or domain; etc

These estimations may also influence external commitments; they may feed some capacity planning or output KPI; they may be part of a larger process where engineers review their agreement on what a 1 Story Point task is; etc

Also: some teams don't do estimations at all, and instead prefer to measure throughput of very small tasks.

The goal is continuous improvement. Whether estimations are a tool to improve planning, measure output or identify knowledge gaps, go ahead and set your goal, apply some changes, measure impact and keep repeating until you like the outcome.