Burn down charts

Is it a fair assumption that these tasks are technical aspects of the stories, as broken down by the Development Team, as part of their Sprint Backlog?

Who uses the separate burndown charts, and for what reasons?

Do they help with that stated purpose?

My suspicion is that the chart with tasks will be less of a true burndown, as it can be quite common for teams to identify new tasks as they work on a story.

A story burndown has the advantage of showing the rate of story completion, and hence throughput, the effectiveness of limiting WIP, and the likelihood of all stories being completed by the end of the Sprint.

A task burndown shows the rate of work being performed irrespective of stories being completed or WIP accumulation. It is a finer-grained measure which may be used to gauge operational working efficiency with respect to a trend-line.

Simon and Ian, thanks for your input. 1 thing I think is beneficial to see is when you compare the task burndown with a story burndown and you see spikes on the task burndown, it could be indicative of poor planning and estimation of stories. I actually like the idea of having a separate burndown by tasks because it provides a bit more transparency of the entire picture. I just never knew that teams use them, hence my questions. It's more of a poll of who uses them and who doesn't. If I am in the minority in that most people use them and I'm out here on my own island, I need step my game and incorporate them. 

Curtis - Just curious, does your Development Team burn down task hours or just tasks?  I have seen it done both ways, and have no opinion on whether one is better than the other, as long as the Development Team finds value.

Ian - I really like how you summarized the differences, thank you.

Chris, my teams do neither. The burndown chart is only done by stories, not by tasks. That is why I thought it was weird when I was told teams do them by tasks as well; I hadn't seen or heard of that. I wanted to see what the general population of the forum readers do with their teams. As in, do they only do the charts by story, or by tasks as well.

I am sorry to say but neither of those burn-down charts are of value and have never been for me and my teams for the following reason = A task can be anywhere from less than half an hour to 4 hours or more! Similarly a Story can be 1, 2,3 or 5 story points (i.e., if you are braking any story bigger than that, which many teams do not want to do in their earlier scrum adaption phase). of course you may not be using user stories for you requirements nor the RELATIVE story point estimation, but the key is that we need to measure the WORK that is done not the number of items (tasks or stories) as they have no meaning without a size.

First let the team estimate the story points relatively (to learn how each story point is worth in hours you need to wait for the end of the sprint and with each sprint this calculation gets better). 

what I am saying is a burn down of 10 user stories each of 2 points (20 points) is not necessarily more than a burn down of 8 stories of 3 points each (24) but actually less!

If you just look at the number of stories for your complete per sprint you think you produced less work (8<10) , while in reality you actually produced more work (24>20). So never measure your burn down in number of items. Without taking into account the relative size, or actual size when it comes to tasks.

I would never encourage to start measuring tasks before you mastered the relative story point estimation. The team will feel micromanaged! They need to understand that the purpose of measuring is to predict how much the team collectively can do in future sprints and not to measure a individuals contribution to the team. This will lead to a lot of empty tasks like documentation, review where the team members try to showcase that they are producing value. I never measure tasks in hours, just an ETA of when each can be finished to let the rest of the team with dependent activities prepare. Once I get the end of sprint I simply measure the total story points delivered by the entire hours consumed. For example a team of 5 will have 5X8X5 = 200 hours (or 180 developer hours, there is a reason for this, not in this topic)

I am on a role tonight I guess being different. My stories and task are so intertwined that I have one burndown chart for both. I do that because as all tasks are closed and many are tied to the definition of done my Dev just closes out all tasks and Marks the story as done.

Hi Curtis，

My teams always use 2 burn-down chart for sprint backlog and 2 burn-up chart for release planning.

The task burn-down chart is not only a finer-grained meature, it show the real work, cost, velocity.

As the development learns more, some tasks may be added to sprint backlog. The new taskd added may increase the story points needed.

We never change the story points of PBIs added to sprint backlog. But the tasks burn-down chart help us to inspect the change.

Recently, I modify the alternative release burn-down chart by Mike Cohn to be used as a task burn-down chart and got positive response from my team.

https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/release-burndown/alternative

@ Dan, that's pretty much what we do. The guy at the meetup further explained that they track tasks in addition to stories so they can gauge how the tasks being done flows with the stories being done. In certain scenarios I think it would be a cool tool to incorporate for teams that are wanting to improve but I just didn't hear of anyone doing that until then.

I have no issues with either we are all agile its whats best for the team and org. 

@ Ching, I totally understand the difference between Task and Story burn downs. I was just curious to see who used both.

@ Dan, exactly.

From a flow standpoint, I can see where a burn-up chart (not a burndown chart) may be beneficial, as a burn-up chart can account for scope changes (adding/removing tasks).   

As Ian pointed out though, a story-based burndown should be used to gauge rate of item completion and likelihood of meeting the Sprint Goal / Forecast.   I could have a task chart where 90 of 100 tasks are marked as complete, yet that tells me nothing about whether any of the forecast items are complete.

Cumulative Flow Diagrams (CFDs) are yet another option for Flow.

+100 Tim. I would rather use a burnup chart for this kind of reporting and I fully agree with your last sentence "I could have a task chart where 90 of 100 tasks are marked as complete, yet that tells me nothing about whether any of the forecast items are complete." Task burn up/down charts can be beneficial but you have to use them with the right team, right mentality, and right goal.

Our burn down charts are too coarse. We use Story Points. One can argue that the PBI's are too big and need to be refined into smaller parts, but slicing the work down ussually make no sense from a technical perpective.

Some of the PBI's are refined into tasks. Some of these tasks are more like check box items (design, develop, test, deploy).

The aim with the Burn Down at the team level is to monitor where they stand and see if corrective actions are needed. So the Burn Down can be based on Tasks i.s.o Stories and maybe even as Li mentioned use two Burn Down's: One on Story level and one on Task level.

But here comes the point. Not all tasks are determined before or during Sprint Planning. So tasks may and will be created if needed during the Sprint. So the amount of Tasks (and even more task remaining time) will change. So a Burn Down based on Tasks will go up and down in stead of down only with pure PBI's.

Estimating tasks is most of the times waste in my book and can be a lengthy process once the Dev team ends in analysis paralysis.

Maybe it isn't so bad as to track progress using the number of undone tasks in a Sprint. The graph may have ups (tasks added) and downs (tasks removed or done), but it gives the Devs a sense of movement and activity.

The teams I have don't use burn down charts at all.  They have found that they can get the information they care about by looking at a physical board.  They can tell the completion rate of stories, they can see the completion of tasks.  They can also see what work is left to be done and make judgement calls on their ability to complete their forecast by end of the sprint.  They all have found that the burn down charts were just another place to have to consult.

As a Scrum Master, I do look back at burn down charts to see if I see any trends.  For example, the infamous "big cliff" that appears frequently can indicate a problem with WIP which can sometimes lead to delay in finishing stories that can provide benefit early. I use those findings to help guide my coaching of the team. But again, my teams do not use burn downs at all and use their physical boards instead.