Agile 101 Estimating delivery dates — part 3: refining estimates to account for changes during development
Introduction
In part one I explained how to estimate delivery for a project that hasn’t started, which is crucial for overall resource planning, managing stakeholder expectations and for helping other teams (marketing, sales, PR etc) to plan around the delivery. In part two I then demonstrated a way to refine an estimate once a project was underway which is crucial for continuing to manage key stakeholders, to refine plans and also to make crucial strategic decisions if it looks like things are going off track. I’ve said it in the previous posts but it’s worth restating: we use the term ‘estimate’ for a reason, all estimates are subject to variability and therefore, it’s important to refine estimates often so as to deal with issues early and maintain good working relationships and a cohesive team.
Why it’s important to account for change within our estimates
Let’s get this straight: you’re going to uncover stuff that you couldn’t possibly have thought of upfront. Not only that, you’re going to experience technical and design challenges along the way and these challenges will require a different approach or change of direction. You’re also going to have to deal with the fact that your pesky users don’t want exactly what it is you’ve given them and refuse to interact with your product the way they ‘should’. Therefore, the best plan is always one that embraces change within it.
So far, so normal but this is where things could go wrong. If you don’t have a way of understanding how change impacts delivery, you’ll be unable to communicate this impact to your stakeholders and associated teams. Very soon, you’re going to land yourself in a right old pickle. The result will be a degradation of quality as sacrifices are made in a desperate attempt get over the finishing line, or your team will burn out because they’re trying to cram too much work into too little time. In all likelihood both burnout and degradation will occur.
The estimation
Luckily, there’s a pretty simple addition to our formula from part two which will help us to calculate the impact of changes on your completion date. ‘Add rate’ is the rate at which you add ‘stuff’ to a project whilst it’s being delivered — it’s a measure of changes in plans. But as before, so long as your chunks of work are measured consistently, for example as tasks, points or the number of stories, you can use this metric to recalculate completion dates.
Number of days to deliver = (CE + WIP) / (CR — AR)
Where:
CE = current estimated size of backlog
WIP = size of work in progress
CR = rate at which you complete work
AR = rate at which you add stuff
Notes:
It might sound obvious but if the add rate is the same or more than the completion rate, you’ll never finish. Furthermore, add rate CAN be negative: if your backlog has speculative elements (and if you’re running experiments that’s fine) you’ll find that prototyping, customer surveys, and indeed any other experiments / activities designed to validate some of your hypothesis WITHOUT building the feature can in fact turn your add rate negative as you drop features (you’re removing more than you’re adding). This will bring forward your expected delivery date.
Using the same examples as in part two, but including add rate:
Example 1 (with tasks):
Project is 18 days into delivery
Initial backlog consisted of 50 stories
4 stories in progress which were broken down to 7 tasks
6 stories complete which were broken to 19 tasks
1 story added
Average tasks per story = (tasks in progress + tasks completed) / (stories in progress + stories complete) = 26 / 10 = 2.6
Task completion rate = completed tasks / days into delivery = 19 / 18 = 1
Current estimated size of backlog = average tasks per story x stories remaining in backlog = 104
Size of work in progress = 7
Add rate = (1 x 2.6) / 18 = 0.14
(CE + WIP) / (CR — AR)
Number of days to deliver = (104 + 7) / (1–0.14) = 129 days (adding 1 story every 18 days has moved the completion date 15 days further away)
Example 2 (with story points):
Project is 15 days into delivery
Initial backlog consisted of 20 stories
2 stories in progress which are estimated at 38 points
3 stories complete which were estimated at 48 points
1 story removed
Average points per story = (points in progress + points completed) / (stories in progress + stories complete) = 86 / 5 = 17.2
Point completion rate = completed points / days into delivery = 48 / 15 = 3.2
Estimated remaining points for project = (average points per story x stories remaining in backlog) + points in work in progress = (17.2 x 15) + 38 = 296
Add rate = (-1 x 17.2) / 15 = -1.15
Number of days to deliver = 296 / 3.2-(-1.15) = 68 days (removing 1 story per 20 days has reduced the completion date by 25 days)
Example 3 (with unsized stories):
There’s a subtle but important difference to the calculation of the completion rate in this example because the project has been running for more than 20 days. I haven’t used the completion rate for the entire project but rather a moving average of the most recent 20 day period because it’s a more accurate reflection of current productivity. The general rule would be to take the most recent 2 or 4 week period for your calculation. Here, I’ve taken the stories completed in the last 20 days.
Project is 85 days into delivery
Initial backlog consisted of 30 stories
Backlog contains 5 stories
2 stories in progress
7 stories complete in last 20 days
2 story added in last 20 days
Current story completion rate = 7/20 = 0.35
Add rate = 2 / 20 = 0.1
Number of days to deliver = ( 5 + 2 ) / (0.35–0.1) = 28 days (adding 2 stories per 20 days adds an additional 5 days to the completion date
I hope this series of blog posts has been useful, if anyone has anything to add or has seen a mistake in my calculations please drop me a line or leave a comment below.
