Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Burn Down chart and a change in scope that impacts the burn down chart

In the previous post (Burn Down Chart), we talked about what a Burn Down Chart is, and how you can use it to get the current status of the project, while not using it as a way of judging the performance of the team. This is because there are many variable that can impact the team, with one of them being changes in scope of the features that are included in the current Sprint cycle.
Typically, if you find that while viewing the burn-down chart that the amount of time available is not enough to do the required number of features / tasks pending, then there are multiple reasons that could cause this. One of the primary reasons is the changes in scope of features in the current Sprint. At the start of the Sprint cycle, when the Sprint Planning was happening, the team would have made estimates based on the user stories (and broken down tasks) defined at that time. Over the duration of the Sprint, there could be inaccuracies in estimates, but as you get a more experienced team, they get better at planning and estimating, and thus the amount of inaccuracies get reduced.
The other primary reason is changes in scope, but how do you show those on a burn-down chart, since the burn-down chart is one of the most used and primary means to determine status in Scrum. One way is to recalculate the chart based on the revised feature scope (although this would mean that the number of features you can do will reduce to account for this increase in scope). Keep an earlier version of the Burn Down chart handy since this helps in forming a sort of baseline.
Another way is to use the Burn Up Chart (refer this location) by Alistair Cockburn; where you can see progress and earned value. The burn-up project shows another line that depicts the total workload for the project, and this can be modified to show changes in scope. If there is no change in scope, then the line remains flat, but if there is an increase in scope, then it is pretty clear that there is an increase in scope, and hence, anybody viewing the graph can quickly make out the difference that the changes in scope have made to the entire project; consequently, the impact on the effort of the team and the amount of work that can be done in the remaining time.
Another thing that the ScrumMaster can do is to take a note of the changes in scope for the tasks as these changes become clear; Scrum is geared towards being as Agile as possible, but in the retrospective, it is always good to review these changes in scope to see which ones are coming because of changing requirements, and which ones are coming because of items that could have been clear earlier in the cycle (these need to be improved upon).

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>