Scrum Log Jeff Sutherland

Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto.

Wednesday, March 07, 2007

Time Tracking is Anti-Scrum: What do you do when you need it for billing?

When we implemented an automated Type C Scrum back in 2002 at PatientKeeper, we did a user analysis of what to ask developers to minimize their administrative time (waste) and lean out the organization. I'm not aware of any other user studies of this type on eliminating administrative waste for developers.

We came up with a counterintuitive answer. While all we wanted to know was how to update the Burndown Chart, our developers told us not to ask about time remaining on a task for the following reasons:

1. It took more than 60 seconds to answer the question for five tasks and 60 seconds was the design criteria for the project reporting system.
2. It made them think too hard and they did not want to be bothered when they thought the resulting estimate was not necessarily accurate.
3. They felt that the estimate of time remaining had high variability and therefore was high risk. If the current estimate was exploding they knew what time they had invested and percent complete. Anything else was pure guesswork.

These were high powered professional engineers. We had several Ph.D.s on the team from MIT and elsewhere. The founders of the company were all MIT graduates. As a result, my view was that they gave the "right" answers to the questions based on best practice and not an answer you would get from inexperienced, perhaps ill-motivated engineers, who knew little about Scrum.

By taking the time invested and percent complete on each task touched each day, the system autocalculates time remaining to update the Scrum Burndown Chart. If a task is 50% done and one day is invested, the time remaining is assumed to be one day. The new total estimate for the task is two days. The original estimate for the task is archived in the system for historical analysis. The Burndown Chart automatically recalculates every estimate for every item touched during a day.

Time remaining to Sprint completion is all that is reported publicly and the team remains focused on what it takes to get "Done" at the end of the Sprint and does not even feel the questions asked relate to time reporting in any way. It is simply the "leanest" way to get the data needed to update the Burndown Chart.

A side effect of this approach is that consulting companies that bill customers on an hourly basis can generate billing from our automated system without filling out any time sheets.

It was generally agreed in a Scrum training class in Copenhagen yesterday with experienced project leaders operating at CMMI Level 5 at IBM and elsewhere that asking developers to fill out time sheets reduces team productivity by at least 10%. They hate to do it, it is duplicate work, it is obviously "waste", and is only done by companies that do not have a clue about lean product development. I have consulted at some companies where time reporting is so complex, developers make up time sheets, the company lies to customers as a result, and senior management make bad decisions on erroneous data, compromising the company's success in the marketplace. My final report to senior management was that 50% of their entire development productivity was lost because of the time sheet implementation.

Any project leader that has any sense will not "waste" 10% or more of development team productivity. They will move heaven and earth to avoid it and get more features done sooner with higher quality.

The recommendation to software development organizations is:

1. Abolish all time reporting.
2. Institute the part of Type C Scrum reporting described above. You do not have to implement a Type C Scrum to do this. How to do it is detailed in the current draft of the book, "The Scrum Papers." For those willing to give editorial feedback, send me email and a copy of the latest draft will be made available.
3. Autogenerate time reporting to the customer from the Type C Scrum approach. Never use it to report development progress.
4. This approach gives more accurate information than any time reporting system ever created:
- Developers never "make up" the data on the time sheets.
- Exact time is available for every task.
- It provides a "micro-costed" analysis of work in progress.
- You never lie to customers. They are billed only on real work.


Blogger Michael said...


Great blog! Learned a lot (as usual). When I saw your "evolution" comic, it reminded me of the one I published just last week at -- while it talks about the evolution of a team member on a scrum team, I thought your readers may enjoy it.

The link is:

Thank you.

- mike vizdos

8:12 AM  
Blogger Indu - said...

Really practical, great read.

12:56 PM  
Blogger Indu - said...

This a great read, very practical .

12:57 PM  
Blogger Guillermo Schwarz said...

Sorry, my English is not that good, what is "a nieve preference"?

10:57 AM  
Blogger Pavel said...

While obviously some companies tend to implement overcomplicated time reporting, you still need "something".

Something to measure iteration progress.

Something to measure team performance.

Something to measure personal performance (you will probably want to reward top performers differently than people on the other side of the list).

Something that makes a predictable and controllable process, even at the cost of certain productivity loss. This is a trade-off, not a waste of course. Just balance it out.

In the end of the day, contractual terms are very much explicit, and you can hardly speak in terms of "more", "sooner" and "higher". That's too vague.

10:40 AM  
Blogger Jeff Sutherland said...

Iteration progress in Scrum is measured by Story Points, a measure of features done. Hours mean nothing except the customer has to pay more for stuff they cannot confirm is done.

In the best companies in the world, progress is measured in cost per story point. This is also the measure of team performance. The customer acceptance tests stories at the end of every Sprint and only pays for stories that are done and ready to deploy. They could care less how many hours the team had to spend. That is the teams problem. The consulting vendor assumes the risk for poor performance.

This is called walking the talk or putting your Agile mouth where the money is.

Individual bonuses are counterproductive on Agile teams. They should be team bonuses. Individuals should be compensated at market rate for their skill levels.

For contractual terms that support this strategy, see my presentation at Agile 2008 at:

A complete paper will be uploaded for the conference by 15 June.

10:52 AM  
Blogger Bill said...


Is there somewhere I can download your paper on Agile contracts?


Bill House

7:41 PM  
Blogger Jeff Sutherland said...

The Agile contract work is going on at:

My Agile 2998 presentation on this can be found at:

8:06 PM  
Blogger K Jackson said...

Great blog! It really challenged some of my thinking.

I just finished a fixed priced contract where we tracked time at the level of themes rather than individual stories or tasks. This worked pretty well as there wasn't much overhead in using the timesheets for billing and at the end of the project we could compare our initial estimates to the actual hours using the timesheets.

I've often found it better to ask "What's left on this story/task?" rather than "What percentage complete is it?" for tracking real progress in a Burndown chart. "What's left" helps to illicit additional tasks and it focuses on the right question - Can we still get this story done by end of the sprint?

10:28 PM  
Blogger Sharmila said...

yes I would like to review "the Scrum paper" however I have some questions:
1. If time tracking is anti-scrum, what is it that proves that we eliminated "waste"
2. How do you measure rework

I agree that some % of data is error prone but this data is just to facilitate the decision and not to rely on the data for decisions. Practically "no time booking" works in a perfect team of mature people however this is not always the case. Secondly I remember a say "if u can not measure something you can not improve it". So time tracking is just a measure and I think it is worth the time. If time tracking is aborted, it does not really guarantee you that that 10% adds to productivity.

I somehow contradict the thought of time tracking is anti-scrum, if everyone owes everything, no one has anything.

11:30 PM  

Post a Comment

<< Home