However, sometimes consultancies and even product companies find they have to bill in hours or collect hours due to unenlightened management. In this case, Scrum data can be collected in a way to give more accurate hourly estimation and completion than traditional planning. In the early years at PatientKeeper, we were experimenting with hyperproductive Scrum and wanted detailed hourly estimation. For several years, we gathered tens of thousands of data points until it taught us we could go faster with point estimation alone (at that time we abandoned any hourly tracking).
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 that have to bill hours 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.
For those organizations not billing in hours, we recommend abandoning time tracking completely and go to only relative point estimate.
Teams that do this have more accurate estimates and higher velocity. See why story points are better than hours.
Spanish 
English 
French