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
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