The key to development estimations with purpose

Time for estimating tasks for the upcoming sprint.

One senior developer looks at the backlog item and shares their opinion: “this is 3 points” or “yup, this is an L”.

The rest of the team members? They swiftly reach the same conclusion. Not always because of their own assessment, but rather due to trusting the more experienced peer.

In other cases, you see thrown onto the table half of the Fibonacci sequence. Or tasks with a similar scope, but high differences in ratings across sprints. And you know. You know, if you’ve been close to the project, that something… is not right.

Sounds familiar?

Ignore that for some time and you’ll end up in a position questioning the entire act of estimation.

My thoughts on this matter and why I find an estimation baseline to be incredibly crucial for the way the development, QA and product streams work together.

Why are you even estimating things?

Let’s start with the basics.

If you're already engaged in, or considering, task estimations, ask yourself: why? Seriously, check this with your team the next time you have the chance.

Estimating development tasks should be useful in the following conditions:

• for PMs / POs: to be able to prioritize and decide which features the team should tackle next. Leaders, when exploring more opportunities than the team can realistically handle in a given timeframe, need this so much. It helps them place a bet into the work that can bring the most impact.

• for developers: to actively assess the complexity, risk and dependencies of a given task and to influence the distribution of work in the team. This reduces the case of junior developers picking tasks they cannot build due to complexity or mid-/senior-developers taking over more than they can deliver.

That is mostly it.

Other objectives, like assessing the team velocity, reviewing professional progress, planning a 12-months long roadmap or preparing nice-looking stakeholder reports I find subjective to every project, so I’ll leave that aside for now.

The issue with on-the-fly estimations

I find that, in software development, relying on inconsistent task estimations is like eyeballing the ingredients for a recipe while cooking.

Imagine adding a pinch of salt without measuring: a little discrepancy might not matter, but wildly varying amounts each time will result in dishes that are either bland or inedibly salty. More accurate measurements, like structured estimations, ensure consistency and quality in both cooking and coding.

While the estimated values should be casted by persons with an active technical role in the team, there are very few cases of “we have a guideline for assessing development tasks” and too many of “just leave the developers pick the value they think”.

Against no baseline whatsoever.

This situation usually brings with it several downsides along the way:

• people end up going with a hunch

• tasks get under- or over-estimated

• work is not finished in the allocated time

• too many unforeseen situations appear along the way. I’m aware that sometimes, as much as you aim to narrow the scope, surprises still show up: aim for only some and not too many

• stories aren’t properly picked-up or distributed within the team

• trivial debates pop up constantly, leading to time lost in planning sessions

And that baseline is a crucial element here, as it can really make the team more consistent and, with that, efficient.

Coming up with a baseline that works for you

I’ll share an example of what I’m talking about below. That might not work 1 - 1 for you or your team though. Instead, as a principle, I’d recommend the following framework in order to define a tailored baseline. 2 scenarios.

If you’re just starting the project and/or the team is new:

1. assemble a core group: include one or two senior developers, a QA engineer and the PM / PO.

2. pick your estimation scheme: it doesn’t really matter if it’s Fibonacci, T-shirt sizes or anything else.

3. decide the criteria: discuss with your group the factors that can or should influence the estimation activity. These may include the complexity of the task, the scope, the time, dependencies or ambiguity.

4. choose the scope for the estimation itself: should estimations relate only to development work, or also to QA activities? It may be easy to develop a new button, but maybe the component it is part of has to be reviewed in 15 different flows later.

5. meet, debate & agree: together with the roles in your group that will directly work on implementation & delivery, map the criteria levels to the estimation scheme and come up with a couple examples of reference tasks. They can be based on common practices or other development work, as for now your team has no prior set of tasks to reference instead.

6. position the result: in the next planning session, showcase the current baseline to the team and ask everyone to account for the guidelines when estimating.

7. monitor and improve: this may not get fully accurate from the first try. Maybe you’ll realise you’ve missed some cases or that the actual tasks don’t match the baseline, which itself is also an estimation in the beginning. It will get better in the next 2-3 sprints. Keep it a living document and adapt it when needed.

8. use it: make sure current or new team members are up to date with the content of the estimation baseline before development planning meetings. Things might otherwise drift away in time and you’ll be back where you started from.

If you’re already deep into a project:

1. assemble a core group: include one or two experienced developers, a QA engineer and the PM / PO.

2. pick the criteria: discuss with your group the factors that are currently influencing the estimation activity. Just like in the other scenario, these can include the complexity of the task, the scope, the time, dependencies or ambiguity.

3. meet, debate & agree: together with the roles in your group that will directly work on implementation & delivery, map the criteria levels to the estimation scheme you were already using and add references from the tasks the team has been working on in the recent past. The ideal starting point here is to pick at first examples positioned somewhere in the middle of your scheme, not too complex and not too simple either. The other references can then be added relative to these, lower or higher on the baseline. Discuss if you need to include or exclude the QA estimations mentioned in the previous scenario (point 4).

4. position the result: present the result to the entire team and ask everyone to account for the guidelines when estimating next.

5. monitor and improve: keep it a living document and adapt the baseline whenever needed.

6. use it: make sure current or new team members are up to date with the content of the estimation baseline before development planning meetings. Things might otherwise drift away in time and you’ll be back where you started from.

An example

Here’s another starting point you may use as a reference when drafting your own estimation baseline. For story points, swap the classes with the Fibonacci scale and divide it more granular if you need.