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. 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.
• 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. Original article