Learn Software Development

Some problems with the usage of Burndown charts to measure status, or to measure progress

ashish — Sun, 21 Mar 2010 17:46:58 +0000

Scrum is touted as one of the modern new techniques that can get rid of all the problems that people have faced with earlier techniques such as Waterfall (and if one goes by correct theory, Scrum is primarily a Project Management technique, not a broad Project Development methodology. However for those people who are passionate towards Scrum, Scrum has always seemed like a solution that can work for most projects. However, people do find that their burndown charts don’t resemble the idea, with the effort needed not trending down to 0 at the end of the Sprint cycle, instead, it happens that the overall effort required remains at the end of the cycle.
This trend can be very frustrating; if you have a team with around 4 developers, and if you find that all of them have some effort pending at the end of the cycle, it could mean that all of them are just there, but not fully. Instead, there are tasks that you need to call out in the end Sprint review, and they need to be carried over to the next Sprint. Now, this would be fine and part of the normal process if the ScrumMaster is able to do a proper diagnosis of why this happened (and there are multiple reasons for why this could have happened), but when at the end, there is no proper reason, it can get very frustrating for the ScrumMaster.
It feels equally problematic when the ScrumMaster has to depend only on the burndown charts for getting the exact status; since the burndown chart is not designed for getting into the required depth (at this point the ScrumMaster would want to get into exact status of various items and compare the current status of all the tasks with the desired level of completion), and if the ScrumMaster does this often enough, they will lose interest in the Burndown chart. A lot of ScrumMasters don’t want to get into the detailed task level status, since it can be tough to then do a root level analysis of which of the tasks were delayed because of reasons that could be prevented.
What I have found (based on some of the teams that I worked with, as well as some friends who were also doing the ScrumMaster bit), we used the Burndown chart as a good indicator for showing to the team how well they are doing (including whether they were running behind and needed to check whether their velocity was good enough); for actual task tracking, we used various scheduling tools (or even used Excel as a way of tracking); it seemed a bit more effort intensive way of tracking, but worked properly and gave us a much better way of control.

The problems with having a large Scrum team – say more than 10-11 people (especially when more people are added to the team)

ashish — Wed, 17 Mar 2010 15:04:03 +0000

In the past, when our teams have been experimenting with how to breakup the overall size of the team into Scrum teams, and we were trying to break the teams up into sizes of 7-9 people (excluding the Product Owner and the ScrumMaster). However, since there were times when there was an effort to accommodate more people (for example, if 2-3 more people joined the product team), there was a lot of queries about whether there is a problem if we increase one of the Scrum teams by 2-3 people, to make a 11-12 member Scrum team. However, this came with its own set of issues, and here is some of our feedback from working with a larger Scrum team.
- As you increase the size of the Scrum team, you get into issues with the Daily Scrum meeting starting to become less of a group and more of a meeting run by the ScrumMaster. You need some regimentation and discipline (to ensure that the meeting runs on time, people make it to the meeting, and so on), but that makes the meeting start to feel a bit more stiffer.
- From the above point, the team stops losing the huge power of empowerment and self-organization; and you need to start getting more documentation and notes of the Daily Scrum meeting to track progress and action items
- One concern that a team has is in terms of splitting an existing Scrum team into multiple teams is about having the same ScrumMaster and Product Owner to handle these additional teams. However, this should not be a blocker since the existing ScrumMaster should be able to handle a new team, and the same with the Product Owner (if it turns out that the ScrumMaster and the Product Owner are over-loaded, then that is a bigger problem that needs to be handled).
- Once you start having more Scrum teams, with them working on the same product or on the same area, then you should consider using a Scrum of Scrums (read more on Scrum of Scrums here) to do more effective coordination and resolving dependencies
- Consider that when the number of teams increases, there is a slight hit since the new team has to start getting into the Scrum cycle and there is some learning and some amount of time before the team start getting into an efficient mode
- However, if you decide to split the team with the addition of new members, then you need to consider the point that splitting teams (especially if you have only 1 Scrum team that now splits into 2 teams), there can be a feeling among team members that they are not getting all the information that they require. This will need more communication and information sharing for some time, before the team feels comfortable again.

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

ashish — Mon, 15 Mar 2010 16:21:31 +0000

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)

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

ashish — Thu, 11 Mar 2010 17:41:19 +0000

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

Burndown charts – a easy and powerful way to depict progress in the Scrum environment

ashish — Wed, 10 Mar 2010 17:58:48 +0000

So what is a Burndown chart ? Seems a slightly weird name as compared to other documents whose names are more descriptive. Well, you will find that this name is also fairly descriptive. The burndown chart is a way to show the progress in a Sprint cycle, and differs radically from the milestone based progress tracking used in other methodologies. So what is a burn down chart ?
Well, a burn down chart tries to display progress in term of what’s remaining versus the time left in the Sprint cycle. At the start of the Sprint cycle, the team would have committed to a certain number of tasks in the current Sprint with the Story Points for each task defined (and thus you know the total amount of points available as well). As time progresses, the team would start completing the tasks, and the number of Story points remaining to be done would keep on decreasing. The amount of remaining Story points to be done by the end of the Sprint is captured in a Burn down chart. The advantage of doing the representation graphically is that it is very quick to make a deduction fro the graph as to whether the team is on track or not; and if the team can view them Burn Down chart on a regular basis, they will also be able to make the same calculation easily. The graph is a plot between the effort and time required, with the effort on the Y-axis, and the time on the X-axis.
In the Burn Down chart, there will be 2 plots, one showing the ideal decrease in Story points over the time period, with the reduction coming to 0 at the exact end point, and the other plot shows how the team is doing for the same time period. Minor variations can be fine, but if it becomes clear that the plot varies distinctly from the idea line, then some effort and planning needs to happen. Given that the Burn Down chart is updated at regular intervals, any deviation from the proposed number of features can be quickly caught and then action taken. However, one needs to be careful of the temptation to measure team performance linked to these charts, since there can be many factors that determines whether the team can meet the ideal curve (for example, if it were determined that the effort for a particular task was under-estimated because of any number of reasons; then the effort available for the total number of tasks will reduce).
Burn down charts provide an excellent way to portray the status of the team in terms of the number of tasks that they can do in the given Sprint, and the same can be used to depict the status on an almost day by day level (in our place, we calculate the burn down chart once every 2 days, and then show the graph at strategic locations around the office so that the current status is pretty clear to everyone).