The Case Against Task Hours Reporting for a Sprint Burn-Down

19 September 2013

Anurag Prakash
American Express



Teams new to Scrum frequently push back on the Scrum rituals and the updates. The most painful of these is updating hours left. In my experience, and that of a few of my colleagues, the hours reporting may be perceived as management keeping the team on a short leash and micromanaging. There may be other reasons, but it's very common for the team to miss out on tasks updates. Moving to Scrum requires a lot of effort in culture change and in acquiring new habits. Process change is the easier part.
 
So I experimented with simplifying the task updates for sprint burn-downs. We were using Rally, which provided pretty good UIs for task updates and sprint burn-downs, etc. This team was used to monthly status reports and informal chat before being told to adopt Scrum. They found the daily update of task estimates to be highly irritating. So we considered few options:
  1. Team members update tasks every two days.
  2. Team members provide task updates every time the estimate changed.
  3. Team members update tasks when they get done.
For various reasons we selected the third option; it's also the simplest. Everything else was done exactly as recommended by Scrum. Breaking down stories in tasks, making estimates . . . the results were pretty good. The burn-down was a good approximation to the Sprint burn-down using daily task updates.
 
Could we simplify the daily task updates even more? Here is the Excel spreadsheet simulation for an even simpler form of Option 3 from above:
 
Simulation Setting
  • 2-week sprint
  • 38 tasks
  • 6-person team; team capacity in hours/day = approx. 6 * 7 hours /day
  • Team updates tasks only as they complete
The sprint planning meeting creates the sprint backlog stories based on velocity and story points. Let's see what happens if we do not track task hours left, but only track how many are remaining.
 
Simulation
  • The team works on a few tasks until they are complete and then picks up new tasks.
  • Task estimates were created using random numbers between 4 and 16.
    • Line 1 plots Total Hours Remaining, when task estimates are updated every day.
    • Line 2 plots Number of Tasks Remaining, when the team updates tasks as they complete them.
The Tasks Remaining line was scaled to the same range as Hours Remaining for convenient visual comparison.

SprintBurndown.png 
 
For the same simulated sprint, if we track the Tasks Remaining it gives a pretty good approximation to the trend line that we get from Hours Remaining. There are a couple of observations we can make here:
  • At the end, the Tasks Remaining line becomes rather rough. We have fewer discrete tasks remaining toward the end of the sprint and so changes are probably not as smooth (statistically speaking). On the other hand, the Hours Remaining line is still rather smooth.
  • As we get to smaller and smaller tasks, the two lines will be closer and closer together. The blue line is the idealized hours burn-down; theoretically if each task were one hour each, the blue and the red lines will be the same. Using 4- and 16-hours tasks, it still produces a close enough trend.

Conclusion
 
If the team follows the guideline of small tasks, tracking the count of Tasks Remaining provides a very close approximation of the progress trend. It may be less painful for new teams to update task completions only and then switch to the full task hours update when their Scrum skills get better.
 
We can use all task estimate = 1 hour in an Agile software tool and mark the hours estimate as 0, when a task gets done. Watch the Sprint burn-down and this may just be good enough for your project.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Phillip Stiby, CSM, 9/19/2013 3:40:51 AM
With the BI hat on its important to understand the report is only as good as measure and data that goes in and its fit for purpose.

For burning down by Estimated time remaining-

The measure, you are reporting on the "Estimated" time remaining. Is this a good accurate measure? Well its an estimate or educated guess, this is not an accurate measure and time remaining for Developer X may not be time remaining for Developer Y. So the value is subjective and inaccurate.

Next the quality of data, well considering we are dealing with humans who are not sat there with stop watches the quality is poor at best. However in most cases its unusable.

Finally, fit for purpose. What is the purpose of this data? The burn down chart is a visual indicator of progress and a means of seeing if the scrum team are likely to meet there sprint goals. So tracking the burn down on estimated hours does not give a good indicator or an early warning if they have over or under committed. So from a scrum perspective hourly tracking is a pointless and futile pursuit which is loved by Project Managers but it does not support or help the team.

Now lets consider the principle of agile, "Working software is the primary measure of progress."

So the measure from a scrum perspective would be the Task's done. As the article stipulates smaller tasks the ideal because they provide a more accurate measures. Daily or less is my recommendation, scrum team members should be getting things Done every day to build up a momentum.

Considering the law of averages the size of tasks may vary but with a large number of small tasks there mean average will be very close, especially using to get a velocity reading of the team. The measure may not be fine grained but its accuracy to size will provide more confident data.

Finally fit for purpose, tracking tasks overtime will high light early over and under commitment, likewise as additional tasks not considered at planning are added the team get a clear transparent picture of the of the sprint status.

The best piece of advice to any scrum team and scrum master is to avoid using real world terms for time. Size stories, and breakdown tasks into chucks no larger that a day. If you want some confidence on time scales then tasks should be 1 hour, 2 hour, 1/2 day and whole day.... So a 20 minute change goes down as an hour, likewise a 2.5 hour change is 1/2 day this allows for the teams communication and time for all additional work not considered.
Anurag Prakash, CSM, 9/20/2013 2:49:13 PM
Phillip,
Good comments. You have set me thinking again :-)
Richard Bell, CSM,CSPO, 9/27/2013 4:39:01 AM
Great article!

In my agile training I usually talk about a hierarchy of units for estimation and burn down, going from concrete to abstract and (IMHO) also complex to simple. The first three levels are Real Time, Ideal Time and Abstract Points. It's easy to show the dysfunction of Real Time using a simple real world example where each person silently applies a whole load of mental baggage to their estimates and then also show the benefit of a more abstract unit by running the same scenario using Ideal Time. Abstract Points are obviously the next step on the abstraction (and relative sizing) journey. But then I would ask the question: "what is more abstract than abstract points?". Often someone is able to make the leap and answer: "no points at all!".

So Card Counting is my final level and commonly my preferred option. For novice teams, this would normally translate to task counting and, as you show, assuming there are enough tasks the average will work out and answer the inevitable challenge "but not every task is the same size!". For more experienced teams, it is often possible to simply count stories since they are able to burn multiple stories every day. Burning a task (or story) is also more meaningful than burning an hour since DoD items can be assigned to the former. And of course additional tasks (e.g. emerging requirements, impediments, etc.) can be added to the sprint backlog as they are discovered and burnt alongside the original planned work.


It's still possible to use a different unit (e.g. Story Points) for estimating PBIs but whilst the numbers do not need to be comparable (although some teams make it so) I always find it useful to at least look at consistency between the Story Points on a particular PBI and the count of tasks assigned to it in SP2. So if a 13 point story ends up with 2 tasks and a 5 point story ends up with 8, something strange (although not necessarily bad) is going on.

You must Login or Signup to comment.