Should a burndown chart be based on stories or tasks completed?

Question

TL;DR; As the title reads: do you base your burndown chart on stories completed, or on tasks completed?

Some background on why I'm asking this: I currently work in a software development team of 4 developers, doing sprints that last 2 weeks. In those two weeks we generally get around 50 to 70 storypoints worth of stories to 'Done'. We regularly have stories that make up 50% or more of those points, say 25 to 40 points. Measuring stories versus tasks leads to the following situations:

Stories: The large stories will be 'doing'/'checked out'/'in progress' for a long time. The burndown will flatline, then when the story gets finished it plummets due to the large number of story points burned. This gives a jagged chart, making it look like suddenly a lot has been done. Also, the flatlining chart doesn't boost the "we're getting stuff done!" morale. Lastly, external stakeholders / other teams may frown at the burndown stalling (minor point, I could care less as long as we deliver in the end).

Tasks: Burning down tasks within stories will give a better impression of the work being done. It will give a smoother line and probably boost morale. My main objective is: it's not displaying actual work done. Work is by default only usable when the full story is 'DONE'. It's great that we've completed a task for the story, but even that last tiny unfinished other task can block the story from being finished and making the sprint.

My gut feeling leans towards burning down stories, mostly due to the fact that tasks can paint a misleadingly happy picture that won't come true at the end of the sprint. I'd rather be skeptic and pleasantly surprised when it turns out for the better. What does your team do?

Answer 1

In order to make the burndown chart useful to the Product Owner (or the customer or the user or another stakeholder), then burning down based on stories is going to be the better option. Since a story is supposed to represent something that is useful and meaningful to the stakeholder, so knowing how many have been completed with respect to your definition of done to-date in the sprint is useful.

However, it seems to me like your stories are too large. If your stories range from 25 to 40 points and you complete 50 to 70 story points in a sprint, that means your sprints consist of 2-4 stories. You should look at ways of grouping stories into epics or themes (which may span multiple sprints) and have smaller stories that show that you've implemented specific (but still useful and meaningful) pieces of functionality and completed it per your definition of done.

Answer 2

Based on previous experience with lots of different approaches, I would agree with your last paragraph - showing anything except true value delivered (tracking tasks, hours, points etc.) often leads to sprints where a lot of items are almost done and very little value is created.

You could also look into ways to break the items up into smaller items (not tasks) so that you are still delivering value but don't "flatline" as much. For example, some of my teams will have an item with a new UI or user-facing component along with implementation, and they will break it up along the lines of "paper mockup and user testing/feedback" and "implement results after user testing", because the team knows that user testing provides value (knowledge).

Answer 3

The answer depends on who your audience is.

If it is for the feature crew (i.e. product owner / developers):

The main purpose of the burn down chart is to show how the team is trending towards completion of the individual work scoped for the sprint. It also helps the team understand how they are doing with estimations (stories and tasks) and should be viewed on the task level. The team should be looking at this several times a week, if not daily.

Some key things to watch out for:

1. Burning Up: This means that the tasks are being created too far into the sprint. A symptom of this is either not enough time is allocated at the start to create tasks or the individuals are not properly planning out their work.
2. Trending Down Slowly: This can be a false positive if the team isn't updating their stuff on a daily basis. If that is the case, show the chart every single day during standup as a reminder. The true positive reason for this is that too much work is being put into the sprint for the team to tackle. If this is the case, focus more on estimation during planning. Learning to accurately estimate is an iterative process that the entire team needs to work together on. (Planning poker and buddies for tasking is a good way to help with this.)

If it is for the stakeholders:

Burn down charts at the task level can still be very useful for them. However, the view they will most likely be interested in is the user stories titles (as those should frame the customer, value and impact) and their current state. A burn down chart of the user stories is less informative for the stakeholder persona.

---

I'd rather be skeptic and pleasantly surprised when it turns out for the better. What does your team do?

As the product owner / scrum master your job is to help the team learn how to be more accurate. Use these tools along with others (retrospectives, for example) to help the team become better.

I currently work in a software development team of 4 developers, doing sprints that last 2 weeks. In those two weeks we generally get around 50 to 70 storypoints worth of stories to 'Done'. We regularly have stories that make up 50% or more of those points, say 25 to 40 points.

It does sound like your user stories are too large. My advice is to take a look at the logical breakdown of the story and ensure that it is focused on delivering the right amount of value. Stories can be bucketed under Features or Epics which span multiple sprints. There are a lot of free resources on this, but I did enjoy this book:

http://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909

Answer 4

Why not base the burndown chart on both?

It has the benefits to show you some insights about what's happening concerning your tasks (so it clearly shows the actual effort) without putting it out of the context of the stories (as it puts the value on top of it).

The most interesting point seems to be that it shows the relationship between effort and value: for instance, on this chart the first two stories show a rapid beginning and then some pain towards the end. Even a plateau in the effort can be found in the second story. On the other hand, the third story shows some pain in the beginning but then it shows a rapid completion in the end.

Matter to discuss for the end-of-sprint meeting. How can we improve this? What does that mean? On the long run, do stories which begin rapidly tend to be painful in the end? etc.

Answer 5

Never use tasks with time estimates. Ever. There are many reasons for this.

1. It's not Agile, for one. We use "working software" not "completed tasks" as a primary measure of progress

2. Estimating in absolute time is impossible. Even if it weren't, your time does not equal my time

3. It's a recipe for old command and control behavior

4. It is no different than a Gantt chart

5. It encourages following a plan instead of responding to change.

6. The work WILL expand to fill the timebox.

7. The developers are talking about tasks and not value delivery.

8. It's deceiving - when 90% of the task hours are done someone will think there's only 10% remaining, when, in fact, it could be another 90% of 150%

9. Results in control charts that can be misinterpeted

10. All this AND it costs us a lot to maintain

11. It encourages specialization

And on and on and on.

Just don't.