Agile 101 Estimating delivery dates — part 1: estimating before the project has started

Introduction

This post covers the estimation of a project before it’s started. In part 2 I’ll discuss how to refine the estimate once the project is underway and in part 3 I’ll discuss how to account for change during the project. I’ve deliberately not covered the ‘how much will it cost?’ part of estimation which can be extrapolated from the following post. However, I’ll endeavour to cover it in detail in a future post.

Why it’s important to have predictable delivery

Sometimes Agile is challenged because of a sense — in some — that it doesn’t provide adequate delivery estimates. It’s true, there’s a lot of debate about the usefulness of estimates and I’ve written here about the pointlessness of getting developers to estimate in units of time.

That said, predictable delivery is generally what all stakeholders seek. Predictable delivery allows others to plan their activities and resources around the development and enables businesses to make strategic decisions based on their set of priorities (for instance, is it more important to launch on a fixed date or to launch later with a particular feature?). Without being able to estimate delivery dates, decisions become impossible to make and stakeholders feel frustrated with the process.

The prerequisites

Given that it’s almost impossible to apply the ‘it will take as long as it will take’ approach (which by the way, also means ‘it will cost as much as it will cost’), it seems sensible to discuss how it’s possible to estimate delivery dates without asking people in your production team to estimate how long individual tasks will take. Luckily this is actually much simpler than you might think so long as you’re capturing the right data. And if you’re running with Agile, whatever the flavour, you better be sure you have the following:

1. A backlog that defines your initial product vision (be that a prototype / MVP / full product backlog — whatever it is you need to estimate). This backlog can be recorded as epics, stories or tasks, whatever you prefer

2. A consistent method of sizing the given units of work (e.g. points / tasks / stories all roughly the same size)*

3. Enough data from previous projects to be able to ascertain your completion rate. Completion rate is the number of tasks / points/ stories (your unit above) that you complete per day. In a perfect world this would be your completion rate for the whole of a previous project (because certain parts of a project can be slower — e.g. the start). For instance: project x consisted of 50 tasks and was completed in 60 days by your team. That gives a task completion rate of 50/60 = 0.83 (your team completes 0.83 tasks per day)**

* If you’re breaking your stories into tasks or sizing in story points, I don’t advocate up-front sizing of your entire product backlog unless it’s really small (and then maybe you don’t need to estimate in the first place). We prefer to identify groups of stories (loosely coined ‘releases’) that deliver distinct customer value, we’ll then prioritise these groups and size the stories in the first group (user story mapping helps to identify these distinct story groups). We’ll then extrapolate the sizes across the entire backlog, replacing the averages with actuals as we incrementally size stories throughout the development process.

** If you don’t have this data or can’t extrapolate it from different sources for previous work then you need to start doing so as it’s going to be difficult to estimate anything until you do. In the case where you have no data my second and third posts will help — you just need to start the work and record your completion rate as you go along so you can quickly build up a picture of your productivity.

The estimation

Your estimate should take the following formula:

Delivery estimate = CE / CR

Where:
CE = current estimated size of backlog
CR = rate at which you complete work per day

Example 1 (with tasks):

Backlog contains 50 stories

First 5 stories broken down into 15 tasks (3 tasks per story)

Task completion rate = 0.8 tasks per day

Current estimated size of backlog = number of stories in backlog x average estimated tasks per story = 50 x 3 = 150 tasks

Delivery estimate = 150/0.8 = 187.5 days

Example 2 (with story points):

Backlog contains 20 stories

Story point completion rate = 4 points per day

First 4 stories estimated as 65 points (average of 16 points per story)

Current estimated size of backlog = number of stories in backlog x average estimated points per story = 20 x 16 = 320

Delivery estimate = 320/4 = 80 days

Example 3 (with unsized stories):

Backlog contains 30 stories

Story completion rate = 0.3 stories per day

Delivery estimate = 30/0.3 = 100 days

There are some caveats to this form of estimating as there is with any form of estimation (we wouldn’t be using the word ‘estimate’ otherwise). Firstly, estimating a project based on the completion rate of a previous project requires a certain amount of consistency between the teams from the two projects. That shouldn’t be a problem for most established cross-functional teams but obviously if you’re going to try to extrapolate a completion rate for a small team of say 2 people, using data from a project which had 6 people then you’re going to have to normalise your data and hope that normalisation doesn’t skew it too much. Secondly, estimating delivery dates, especially if the backlog is on the large size can be subject to a great deal of uncertainty because a backlog is by it’s nature speculative. The more you try to estimate the less likely you’re going to be accurate with that estimate (the only thing I can guarantee is that it will take me 0 days to do 0 things but sometimes it takes me a few days to do 0 things.

I would always advocate stripping the backlog back to the barest MVP and only trying to estimate that at the most whilst only ever spending time on sizing the next highest priority bit of customer value. Everything else is subject to too much change.

I hope this has helped you to understand how to estimate delivery dates before your project has commenced. However, in part two I’ve written about how to extend this method to get more accurate delivery estimates (and refine your estimate) once a project is underway.