Scrum Burn Down Charts: Tasks or Stories?

Question

There are several ways to do burn down charts in Scrum.

Some people suggest using the story points of unfinished stories left as your burn down charts in Scrum.

Pro: Only finished stories lower the chart

Contra: Chart doesn't move down in the beginning and then rapidly falls off

Others suggest to use the number of tasks left

Pro: Chart will move down, you can see if it is above the finishing line

Contra: You could move down to say 10 tasks left (hard tasks) in the end, and still have not one story finished. You've failed because only finished strories are good for your product owner.

Is the solution to have both a points-of-not-finished-stories and a not-finished-task chart?

Stephan

Answer 1

We do both, as if we didn't include tasks our line would plateau in a way that makes it look like nothing is getting done.

If a story takes 2 days to finish, then you have a flat line for 2 days, and there's no way to tell whether the team is sitting on their thumbs, or that work increased (thus a jump in task hours).

Of course the task line can plummet without contributing to finishing stories, which is an anti-pattern that can occur if developers can choose tasks at will.

Answer 2

Tracking the number of remaining tasks is not very helpful as the tasks are likely to have different sizes.

You should not find yourself in a situation where the team complete ten tasks and no backlog item (actually, this is possible if you have ten developers) : every developer should not pick up tasks from another backlog item (story) until he completes the backlog item the first stories he did belongs too - event if the task form the other story is harder than the remaining tasks from the started sotry.

Answer 3

In my opinion, tracking tasks is a rather suboptimal approach to tracking. In my experience, a story seldom really is the sum of its tasks - and often, while implementing a story, I find that the task breakdown was suboptimal, anyway.

And, while I find value in brainstorming tasks while estimating a story, I prefer to have stories that are small enough that there is no urge to track them at all. In fact, getting credit for tasks finished is highly misleading, as having even half of all identified tasks finished still isn't any guarantee that the Sprint will deliver any value at all. And that's what the stakeholders are interested in in the end: how much of the projected value will be actually delivered?

So, tracking stories and working on further breaking down stories both gives more accurate feedback and reduces the risk of no value delivery.

Actually, when working with small stories, I don't see much value in Sprint burn down charts at all - just watching stories on the wall of cards move from "to do" to "in progress" to "done" should give you all the information you need. A Release burn down, though, that can be quite valuable, in my experience.

Answer 4

We are using remainig time for sprint burndown - teams can see progress every day. If there are flat parts, than they really occured.

In the release burndown we are using story points. Release planning is more about he feature completness, the time is tracked on the sprint level. Product owner is interested in completed stories.

Number of tasks is useless. This number can be changed every day, especially if you give a "freedom" to developers. They can split the task to smaller part without the change of the total time. Such statistic is useless. What is it indicating? Does it affect the goal of the sprint?

Answer 5

We usually need to track hours (estimate vs actual vs estimate to complete) against stories for the clients who asked for them. This allows us to do a few things:

1. Track progress for that client's needs so their project manager has some insight into what is happening.
2. Review estimates against actual work required in order to improve our estimating ability.
3. Bill clients for time actually spent in case it is part of an hourly rate job.
4. Give developers feedback about their progress so they can manage distractions appropriately.

We also track completed stories for our own burndown, but as has been pointed out this can lead to a plateau effect at the start of the sprint that serves to tell us very little useful info (other than that we're not doing enough in parallel).

Answer 6

We use tasks because it provides so much more granularity. Graphing only the completion of stories (which we do 5-10 per two-week sprint) will only show a change every day or two and, as you mention, won't move much at all during the beginning of the sprint.

Another useful thing my team has found is using a stacked line chart with one line for each of "To Do", "In Progress", "Ready for QA", and "Validated". This way it is easy to see any phase in the process that is creating a backup.

Answer 7

I used a lot the "hours remaining" for burndown. Team always find that tracking burndown by time is close to time tracking system, add overhead of administration and is really not accurate unless we transform humans to robots.

I am using tasks burndown (total tasks, new tasks, done tasks). Much much better. It is true that you do not see the size of the tasks that are done or new. But team meet everyday and that's where you catch problems. As well, I coach team to not create big tasks (4 to 6 hrs max). Also, I added an other chart with New tasks and Done tasks by day. Team found that the burndown by tasks make more sense that using hours.

After the team understand the values of breaking down stories in tasks, I want to try burndown by stories. So having small stories with a max of 5 or 8 story points. From Jeff Sutherland blog, this is a big step to get a team to high perform.

In addition, I'd like to mention that a burndown is just a "At a glance representation of progress". Most important and even more relevant for the team and PO's are: what is being mentioned in daily about the tasks + story progress percentages + list of impediments. After a while, management and team members don't care much about the burndown (or burn up).

Answer 8

Burndowns (or even "burn ups") should only indicate work remaining.

If you've half done a story you can't ship it, and it doesn't count. If you end the spring with a story half-done - tasks that were done in it don't count if you're measuring velocity.

Just chart stories left to be completed.

This is a tougher measure but there's no use massaging the figures - scrum is supposed to communicate bad news so that things will get fixed.