Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1


This post covers the estimation of a project before it’s started as a primer for creating emergent estimates during delivery. 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 because you should be able to figure that out if you know how long something is going to take your team to do.

I’ve used the term ‘estimate’ and not ‘forecast’ although I accept that using data to inform estimates is probably more of a forecast. Whilst for some this might be a bit irritating, in the main I encounter people who use the term estimate for everything (including in literature) so I wanted to stick to terminology that people are used to.


Smarter people than me will point out that this form of estimation (estimating something new from data from something old) can be risky unless you’re estimating something very similar with the same / similar team. Which rarely happens. However, it’s the basis of the principle described by Eric Brechner in his very good book Agile Project Management with Kanban (Developer Best Practices) and can be used for providing better estimates (’emerging estimates’) as you move through development (see part 2 and part 3). I’ve also included some caveats below.

Why bother with estimates?

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 business 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 capability?). Without being able to estimate delivery dates, business decisions can become difficult 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. Things that you should consider having:

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). Ideally these will all be 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 can then extrapolate the size of the entire backlog, replacing the averages with actuals 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

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 I mentioned in my health warning above. Firstly, estimating a project based on the completion rate of a previous project can be very risky when there can (and usually are) many difference between the projects. But if you’re going to do it, it 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 (which it probably will). 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 if sizing is the way you do things. 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 and also understand some of the basic concepts around forecasting using data. 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 – AKA ’emergent’ estimates.