Is there some tweak that we can make so the burndown is derived only from work remaining without a person reporting how much work they completed?

With the 1.0.1 release (just announced -- https://jazz.net/downloads/rational-team-concert/releases/1.0.1?p=news), Time Remaining can now be used instead of Time Spent (scroll about halfway down the article).

Despite Mr. Schwaber's stance, I think there are some personal insights to be gained in understanding how well your estimates turn out and using Time Remaining won't guide you to them. If I can look back (query my Work Items) and see that most of them ran over and that most of them by 20%, I might figure out how to plan better in the future.

Since the focus is on transparency and the team being successful, I'm not sure how much good it does one or more people to pretend they were working harder than they were. We know who they are, anyway. ;-)

But... tracking hours worked is fundamentally at odds with Scrum... One of only two statements in bold that I've seen Ken Schwaber make in Agile Software Development with Scrum is this:

"Work remaining reporting updates the estimated number of hours required to complete a task. This should not be confused with time reporting, which is not part of Scrum. There are no mechanisms in Scrum for tracking the amount of time that a team works. Teams are measured by meeting goals, not by how many hours they take to meet the goal. Scrum is result oriented, not process oriented."

So, the burndown should focus only on work remaining, never on how much work the team has done....tracking hours worked drives a negative behavior. You can imagine someone inflating their hours so a manager (or the Scrum Master as a representative of management) looking at the chart sees how "hard" someone is working.

I'm curious to know how others are dealing with this.

-elizabeth

We've had similar issues come up with teams wanting to just report time remaining and not worry about anything else. I think there's two possible approaches here. If you're not using RTC for anything beyond tracking immediate needs (i.e. work of the current iteration), then you might be able to get away with only updating the time remaining field. However, I'm not sure of the impact of this on progress bars and historical data such as burndowns. If you want to use the results in predicting future commitments, then I think you need all three pieces of data (regardless of whether it's time spent or time remaining).

To illustrate this, lets start with a task that is 8 days of work. Four days into the task you realize that it's really 12 days of work and set the time remaining to be 8 days. If you haven't updated the time remaining in the previous 4 days, it looks like no progress has been made in the burndown/progress, even if 4 days of work has been accomplished. If you have updated it (e.g. 7, 6, 5, then 8), then it looks like you threw away your work and started over rather than recomputing the total effort of the work. I'm not sure what it does if your time remaining exceeds your initial estimate since it looks like negative amounts of work has been done. If the percentage of change is large compared to the iteration content, it could significantly regress percent complete on the progress bar. At the end it looks like you only got 8 days of work done rather than 12 days.

I'm not sure if there's any easier way to approach the problem. I know our teams would like to get away with not having to update the correction field. Any ideas?

Doesn't the correction field on the estimate give you the ability you describe?