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.

Burndown charts and Scrum – Some issues and problems that people encounter

Burndown charts are a key part of Srum; after all, what could be better than a chart that shows a well defined path to reaching the end of the Sprint with all the tasks done in the allotted time. The Burndown chart at any point in the Sprint shows a status of where the team is with respect to doing all the tasks as well as the amount of time remaining.
However, does everybody see a smooth Burndown chart ? Well, unfortunately a number of people do not see Burndown charts with a smooth curve or line that trends to the zero point for tasks at the end of the Sprint cycle. People have reported Burndown charts where the curve goes all over the place, with getting a status reading not being so easy to decipher. One could say that this was because of the Scrum process not being fully well implemented, but the fact is that many teams feel that they are working through the Scrum process correctly, and yet do not see the Burndown charts as they see them in theory. What are some of the problems that ensure that the Burndown charts do not reflect the way that the tasks line is declining, or hitting zero at the end of the Sprint ?
– Well, one of the simplest problems is that the team has not been able to accurately define its estimates (and this could be because the team is inexperience, or that the information that the team had when developing estimates was not complete)
– Another problem is when the scope of the tasks increases and as a result, the amount of effort that the team has to put in to ensure that the tasks are done within the required time frame increases
– The team used a certain design principle when estimating the tasks, and then realized that the design that they needed to use during actual implementation was different; and this design change caused an increase in the amount of implementation effort and estimation
– To some extent, the variation in the Burn Down chart is when the tasks have not been broken down into discrete level tasks; as a result, when the tasks start to get completed, the level of completion of the tasks (as tracked in the Burndown Charts) can go all over the place and lead to confusion in the team
– When there are changes in the team during the process of a Sprint, there can be differences in the estimation and development abilities of the people involved; this in turn causes some amount of variation of the Burndown charts
– In earlier posts, we have talked about impediments and how these need to get resolved; however, when these impediments do not get resolved early enough, they can cause problems in the progression of the tasks in the Sprint (in addition to the morale issue when impediments are not resolved)

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>