One of the questions that Project Managers always pop up during projects is: “how many days will it take to finish this work?”. This is a very natural and sensible question. You want to know when a project will be finished, so people can have an expectancy of the needed budget, what functionality is in it and when it will be finished. However, answering the question is more difficult than traditionally is assumed.
An illustration
Imagine you’re expecting a friend from a distant city, to come over to your house for a visit. The city is 150 miles away. He’s been traveling for a while and you want to know how long it will take to arrive to your house. You expected him to make the trip in three
hours. You give him a call and pop him the question. “How long will it take for you to get here?”. Imagine him answering “I’ve been traveling for two hours”
What kind of conclusion can you get from this?
- Maybe it would be:“great, normally it takes three hours to travel, so he should be here in one hour. Everything is going according to my plan”.
- Another conclusion could be ‘I traveled the same distance last Saturday and it took me three hours an so he should be here in one hour.’
Hopefully however, it is obvious you cannot make any conclusions at all. You have no idea of the progress that has been made and you have no idea of the speed at which your friend is traveling. Any conclusion you’ll make based on this answer, will have an assumption in it, and probably a bad one. It assumes that the situation you’re friend is in, is comparable to some hypothetical situation you have in your mind.
Basically, the only reliable data, is historical data.
Continuing the story, your friend eventually arrived. It took him five hours to complete the 150 miles, due to a big traffic jam just a few miles of your city. And by the way, your friend has an old car that doesn’t travel faster than 62 miles per hour. So what could your friend have said for you so you could have the best base for a guesstimation of the ETA? Basically, the only reliable data, is historical data. Obviously, if your friend has never traveled the course before, there is no historical data. His most reliable answer would then be:
“I’ve traveled 90 miles so far and my average speed has been 45 miles per hour. I cannot give any guarantee at what time I will arrive, since there might pop up something unexpected. However based on my current progress and velocity, I expect to arrive in one and a half hours.”
Notice that the elapsed time is of no relevance to make a prediction, once you know the speed and progress that has been made so far.
Bringing it home
So back to the project manager’s situation. What can we learn from this? “When will we finish?”
- First of all, software development projects tend to be complex and unpredictable. There’s is no way you can beforehand guarantee at which point in time, you’re going to deliver x functionality for y budget.
- Second, to measure progress, you need to know at which speed the development team is making progress. You’ll have to find a way to make that transparent. And here’s a clue: time is in no way a measure for progress. The only measure for progress is delivered value.
- Third, you cannot project your hypothetical situation or even your own experience with teams to the situation of other people, let alone a whole different team. Situations differ, because people differ, teams differ and organizations differ. This alone creates a unique and beforehand unpredictable dynamic. In the hypothetical assumptions that are usually the base of ungrounded guesstimations, the team is working without interference, independent of surroundings and with everything available and no unexpected things taken into account.
So how to do it?
- To measure progress, make beforehand a rough estimation of your to be implemented functionality in story points. Story points are an indication of the amount of effort that needs to be performed to finish a piece of functionality. This is comparable to the number of miles to be traveled and has no element of time in it.
- Next, keep track of the finished story points in time during your project. This is an indication of the team’s velocity. It doesn’t give you any guarantees about the future, but it’s the best data you can have, since it’s data extracted from the real world.
- Third, as you go through the sprints, regularly do a re-estimation of the backlog that still needs to be done. This, in combination with the teams velocity, will give an indication of when your team will have finished the work.
- Finally, don’t ever do fixed time, fixed budget, fixed functionality. No really, don’t do it. My personal preference goes to fixed time, fixed budget, flexible scope. Most of the time, people won’t remember if you’ve missed a piece of functionality. However, you will be remembered for a missed deadline.
Ignore history at your own peril.
Reference: Why Time Is No Measure For Progress from our JCG partner Arthur Arts at the Agile Arts blog.
Hmm, I do not quite agree. You have made a valid point that having the ‘history’ as you call it is better than having the ‘time already spent’ information. But it is not true, that time already spent is not a reasonable predictor of ETA. The project manager is in fact not looking for a causal relation (I agree that there is none), but for a known variable(s) that can be used to estimate an unknown variable. Now, given the level of abstraction at which we discuss, I’m unable to demonstrate it, but I’m willing to bet that var1=time it… Read more »
Hello David, thank you for your comment. I do agree that time spent *could* have some predictable value, but only when the teams work in very similair situations. In that case, you already have some historical data about the dynamics of the environment the teams work in. However, teamdynamics can also differ very much and this alone could cause a very different outcome to how another team works. I do stress again that time spent is no more a measure for progress in teams, as the amount of time spent travelling is in the example. If your team runs into… Read more »
Hi Arthur, thank you for interesting article. Unfortunately in your “How to do it section” you made the same mistake by estimating effort. You said “Story points are an indication of the amount of effort” and when dealing with story points and velocity you have a formular to translate effort into time – but it has – as you said before – no relation to delivered value. I’m a CSP, but it turns out to me that the story point thing is a new name for the same old mistake we made before. Another good article i have found ist… Read more »
Hi Guido, thanks for your comment. When I mean “effort”, I mean the ‘amount of work’ of the story (sort of). The idea is that you compare stories based on the amount of work. If you keep track of history, you can look in hindsight and say “okay, previously we managed 20 points in two weeks. Given roughly the same conditions, these stories are roughly the same amount of work, so it should also fit in two weeks’. It’s apparant that in professional environments, people want to have an idea how much time stuff takes to deliver, so you time… Read more »