Does a burn down chart work with scrum?
Hello community,
currently I am preparing for the PSM 1. I read the scrum guide and saw some videos of Ken Schwaber telling something about the burn down chart.
I think I understand the burn down chart but think to implement it, it is necessary to "break" some scrum rules.
1. Burn down to track a whole release (over several sprints)
The Y-Axis corresponds to the Product Backlog Items (PBI) and shows how much work is left.
The X-Axis corresponds to the remaining time.
Does't it mean that I have to have a fix product backlog up to the end of the release? But within the scrum guide it says "Requirements never stop changing, so a Product Backlog is a living artifact". This does mean for all the items spanning the release they should not change or the burn down will change continuously, but than it is hard to figure out a trend.
On the other hand the development team must start of investigate on the PBIs which are planned several sprints later as without a estimate the PBI can not be mapped to the Y-Axis. Here I think I understand why there is a product Backlog refinement. But what I also understand is that this is a compromise between doing things as they become relevant and planning things in front of a release.
2. Burn down to track the ongoing sprint
In a project we tracked it on stories which leads to burn down charts which said nothing as the became clear enough only at the end of the sprint. The granularity was not fine enough.
On task base it makes more sense but it leads to discussions about what happening with the PBIs which has not been finished. There it says that one PBI is finished to 90%, lets say just testing was missing. But in scrum you should not count on anything which is not 100% finished, as this is not transparency.
(People like to count these things as almost done. The PO likes to see more things ready, the users are asking why they could not get the feature in earlier and the developer likes to have the prestige of having more done within this sprint.)
So we have way of using burn down chart. First variant lets us do planning in advanced (maybe not too much but more than we would do without it. The second one brings us in trouble with the concept of transparency (Maybe it can be clarified easily but it is still does not correspond to the nature of scrum).
In many aspects the burn down is very help full and let us make forecasts to the end of a sprint or a end of a release but in my opinion it must be payed by soften the principals on scrum.
Didn't I understand something wrong on scrum? Or is there a perfect way to implement the burn down chart?
Kind regards
Benjamin
Hi Benjamin
Yes, burndown charts work with Scrum. They do not require any compromise to be made regarding Scrum rules (apart from Release Burndowns, see later). They are typically applied in two contexts: the Sprint Burndown and the Product Burndown. In both cases, the burndown charts show work remaining.
The Sprint Burndown shows the work remaining in the Sprint. Days are on the X axis and task hours are on the Y axis. These task hours are typically estimated during Sprint Planning. Note that you don't have to use tasks; a Sprint Burndown could show the total planned user story points on the Y axis, and therefore story point burn. Note that no story points can be earned for a story until it meets the Definition of Done; task hours do not have this constraint. You can see that there are advantages and disadvantages to either system.
The Product Burndown shows the work remaining in the Product Backlog. It is a rule in Scrum that every item in the Product Backlog must have a size. The Product Burndown has the Sprints on the X axis and the total Product Backlog size on the Y axis (typically as story points). You then show the burndown of story points on a sprint by sprint basis. Again, no story points can be earned before the story fully meets the Definition of Done.
Now, as you rightly point out, backlogs change. Work can be added, resized, or removed. This means that a burndown (Sprint or Product) might actually trend upwards at bit at times. For example, new tasks might be added mid-Sprint, leading to a spike in the Sprint Burndown, or new user stories might be added which push up the Product Burndown.
One response to this is to use a burnup chart instead, which shows work done rather than remaining. Another twist is to track actuals in terms of number of user stories or number of tasks actioned. Again, there are advantages and disadvantages to these systems, but they are rarer than burndowns.
You mentioned Release Burndowns. These are a bit controversial, in so far as they imply that release planning has been done. This in turn implies (but does not prove) that releases are not (or cannot be) done on demand, and that each end-of-sprint increment is not potentially releasable. That potential releasability is a Scrum rule. Nevertheless, the mechanics work in the same way as a Product Burndown, except that the Y axis expresses the story points (or whatever) that have been sized for the release only.
Hello Ian,
thank you for your reply. Good to know that I was not totaly wrong about the release burn down.
The burn up chart (should it not be renamed in build up chart?) is an interessting way of visualize the velocity as the curve is not interrupted by some spikes, due to the changing PBI.
Here it started to get clear for me that the burn down let you forecast a point in time when your work has been finished. But it does not show the velocity; not direct as the spikes are resulting from additional work through changing requirements. But this is not the intention.
And as you do not do extra work to better forecast anything it for sure does fit perfectly within the scrum process. So the burn down should be allowed to change as the PB changes.
Thanks again getting into the right direction
Kind regards
Benjamin
The meanwhile I found another answere in the Book "Software In 30 Days" within the chapter "Scrum at the Project Level".
There a Revised Net Baseline is introduced to show changes on the Backlog. In addition I found an example for it in the following thread: http://www.mountaingoatsoftware.com/agile/scrum/release-burndown/altern…
Kind regards
Benjamin