About Arthur Arts

Arthur Arts is an experienced Enterprise Java software engineer and hands-on Agile Coach and Scrum Master. He has a strong focus on agile engineering principles and practices and loves to share his knowledge and learn from others. He currently works for JDriven and also works as a photographer, pastor and writes for agilearts.nl

Why Time Is No Measure For Progress

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.

Related Whitepaper:

Applying Agile Principles To The Development of Smarter Products

Agile development has become a cornerstone of most software development organizations.

Marked by iterative processes that deliver incremental value over time, agile development has enabled organizations to manage software complexity more effectively and to improve quality and time to market compared with previous development processes.

Get it Now!  

4 Responses to "Why Time Is No Measure For Progress"

  1. David Voňka says:

    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 took another team to do this task and var2=time already spent by this team will have reasonable predicting power on ETA of this team.

    Furthermore, the information on time already spent is relatively _cheap_, while getting the ‘history’ is way more expensive. I do not necesarily mean cheap in sense of money. There will be quite some people, who will be able to give you the time spent, but unable to make a usable description of the history.

    Btw, I think your text is very useful, I just felt like making a maybe somewhat academic comment.

    • Arthur Arts says:

      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 some very heavy impediments, the time will pass, but your progress will not.

      I don’t agree that getting is history is expensive. It’s as simple as keeping track of the teams burndown charts over the sprints. If you work in sprints of two weeks, than within two weeks you have gained ‘historical’ data.

      The idea is to steer on the actual progress you make, instead of holding on to a prediction you made at the very start of a project.

      Thanks for your remark!

  2. Guido Zockoll says:

    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 Ron Jeffries: Estimation is Evil (http://pragprog.com/magazines/2013-02/estimation-is-evil)

    • Arthur Arts says:

      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 will have to get in to the equation somewhere.

      Ideally, you wouldn’t have to make estimations and then things go simply as they go, but that’s not how IT works for most people. People want to know when things are finished and it’s up to us to make things transparant. Time doesn’t make the progress made transparent, delivered value does.
      Thanks!

Leave a Reply


two × 8 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books