Measuring the time left
That is if, like me, you work in what might be termed a semi-agile*1 arena then you also need some hard and fast numbers. What I am going to talk about is a method for working out the development time left on a project that I find to be pretty accurate. I'm sure that there are areas that can be finessed, but this is a simple calculation that we perform every few days that gives us a good idea of where we are.
The basis.It starts with certain assumptions:
You are using stories.OK, so they don't actually have to be called stories, but you need to have split the planned functionality into small chunks of manageable and reasonably like sized work.
Having done that you need to have a practice of working on each chunk until its finished before moving on to the next, and have a customer team test and accept or sign off that work soon after the developers have built it.
You need that so that you uncover your bugs, or unknown work as early as possible, so you can account for them in your numbers.
Your customer team is used to writing stories of the same size.When your customer team add stories to the mix you can be confident that you won't always have to split them into smaller stories before you estimate and start working on them.
This is so you can use some simple rules for guessing the size of the work that your customer team has added but your developers have not yet estimated.
You estimate using a numeric value.It doesn't matter if you use days work, story points or function points, as long as it is expressed as a number, and that something estimated to take 2 of your unit is expected to take the same as 2 things estimated at 1.
If you don't have this then you cant do any simple mathematics on the numbers you have and it'll make your life much harder.
Your developers quickly estimate the bulk of the work before anything is started.This is not to say that the whole project has a Gandalf like startup: "Until there is a detailed estimate, YOU SHALL NOT PASS"; rather that you T-shirt cost, or similar, most of your stories so that you have some idea of the overall cost of the work you're planning.
You need this early in the project so that you have a reasonable amount of data to work with
Your developers produce consistent estimates.
This tends to be the case if the same group of developers estimate all the stories that they all involve making changes to the same system. If a project involves multiple teams or systems then you may want to split them into sub projects for the means of this calculation.
You keep track of time spent on your project.Seriously, you do this right?
It doesn't need to be a detailed analysis of what time is spent doing what, but a simple total of how much time has been spent by the developers, split between the time spent on stories and that on fixing defects.
If you don't do this, even on the most agile of projects, then your bosses and customer team don't have the real data that they need to make the right decisions.
You, and they, are walking a fine line to negligent
The calculation.The calculation is simple, and based on the following premises:
- If your previous estimates were out, they will continue to be out by the same amount for the whole of the project.
- The level of defects created by the developers and found by the customer team will remain constant through the whole project.
- Defects need to be accounted for in the time remaining.
- Un-estimated stories will be of a similar size to previously completed work.
The initial variables:
totalTimeSpent = The total time spent on all development work (including defects). totalTimeSpentOnDefects = The total time spent by developers investigating and fixing defects. numberOfStoriesCompleted = The count of the number of stories that the development team have completed and released to the customer. storiesCompletedEstimate = The sum of the original estimates against the stories that have been completed and released to the customer. totalEstimatedWork = The sum of the developers' estimates against stories and defects that are yet to do. numberOfStoriesCompleted = The count of number of a stories that have been completed by the development team and released to the customer. numberOfUnEstimatedStories = The count of the number of stories that have been raised by the customer but not yet estimated by the development team. numberOfUnEstimatedDefects = The count of the number of defects that have been found by the customer but not yet estimated by the development team.Using these we can work out:
Time remaining on work that has been estimated by the development team.For this we use a simple calculation on the previous accuracy of the estimates.
This includes taking into account the defects that will be found, and need to be fixed against the new feunctionality that will be built.
estimateAccuracy = totalTimeSpent / storiesCompletedEstimate predictedTimeRemainingOnEstimatedWork = ( totalEstimatedWork * estimateAccuracy )
Time remaining on work that has not been estimated by the development team.In order to calculate this, we rely on the assumptions that the customer team have got used to writing stories of about the same size every time.
You may need to get a couple of developers to help with this by splitting things up with the customer team as they are creating them. I'd be wary of getting then to estimate work though.
averageStoryCost = totalTimeSpent / numberOfStoriesCompleted predictedTimeRemainingOnUnEstimatedStories = numberOfUnEstimatedStories * averageStoryCost averageDefectCost = totalTimeSpentOnDefects / numberOfStoriesCompleted predictedTimeRemainingOnUnEstimatedDefects = numberOfUnEstimatedDefects * averageDefectCost
Total predicted time remainingThe remaining calculation is then simple, it's the sum of the above parts.
We've assessed the accuracy of previous estimates, put in an allocation for bugs not yet found, and assigned a best guess estimate against things the development team haven't yet put their own estimate.
totalPredictedTimeRemaining = predictedTimeRemainingOnEstimatedWork + predictedTimeRemainingOnUnEstimatedStories + predictedTimeRemainingOnUnEstimatedDefects
The limitationsI find this calculation works well, as long as you understand its limitations.
I hope to present some data in this blog very soon, as we already have some empirical evidence that it works.
Admittedly, for the first 20% or so of the project the numbers coming out of thus will fluctuate quite a bit. This is because there isn't enough 'yesterday's weather' data to make it the estimate accuracy calculation meaningful. The odd unexpectedly easy (or hard) story can have a bit effect on the numbers.
Also, if your testing and accepting of stories lags far behind your development or if you don't fix your bugs first, you will under estimate the number of bugs in the system. However, if you know these things you can react to them as you go along.