Sprint Burndown Chart vs. Product/Release Burndown Chart

(Here’s some advice I recently gave some folks I’m coaching. –mj)

The Sprint Burndown chart and the Sprint task list are intended to be *internal* metrics to help the team see how it’s progressing during the Sprint. How to maintain them are intended to be team decisions. So I don’t have a recommendation for whether to nag team members to update their “hours remaining” per task in ScrumWorks or to ask them for the updates and enter them yourself (as ScrumMaster). I’ve done it both ways and they both worked.

I *do* recommend keeping the task list and burndown chart visible during the daily scrum meetings to emphasize that they are all owned by the team rather than whichever individual volunteered to be point person. I like projectors for this, but your big LCDs set to crayon mode seem to work. I’ve also used a physical task board with 3×5 cards for this.

The contract with the Product Owner are the Sprint Goals and the list of Product Backlog Items negotiated during the planning meeting. The subordinate Tasks (and the Sprint Burndown Chart) are in the team’s domain.

While Product Owners like to peek at the Sprint Burndown Charts, I’d invite them to let the team work out the “how” while still holding them accountable for the “what” during the review meeting. If the Product Owner intervenes or over-scrutinizes during Sprint Execution the team will feel less responsible for the “what,” slower to self organize, and less candid about what they put in the task list and impediment list.

Of course Product Owners are entitled to apply pressure/motivation to teams (or even shop between teams). I suggest doing this during the Sprint Planning Meeting and Sprint Review Meeting, at the Product Backlog Item level, and resist the temptation of doing it during Sprint execution down at the Task level. I can attest to the fact this is difficult to do because I’ve been in the Product Owner role before.

At the review meeting your team will demonstrate what it built and we will all look at the acceptance criteria (definition of “done”) for each Product Backlog Item. If the Product Owner is satisfied the acceptance criteria are met, he (or you) will check the “Done” checkbox for the item. Over time, this will feed the big picture metrics necessary for release planning: the Product/Release Burndown charts, the release rollup dashboard, and the Sprint Change Report. I’m happy to talk about these (or anything else) with anyone who’s interested.

Download the PDF version: Sprint Burndown Chart vs. Product_Release Burndown Chart blog

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
2 comments on “Sprint Burndown Chart vs. Product/Release Burndown Chart
  1. Anonymous says:

    I like the point “Keeping burn down chart visible during the daily scrum meetings”.
    I have to do it for my team from this sprint.

  2. Tariq Khan says:

    I believe to have three of them separately, Daily progress is shown during a single sprint burndown chart. The second chart showing the number of all planned Sprints up to the release on X-axis and total story point up to release comprising of all the sprints before releasing on the Y axis and a separate velocity chart, the relationship of all these three charts can give a better picture.

Leave a Reply

Your email address will not be published. Required fields are marked *