Burndown Analysis for Managing Productivity & Schedules
Managing the productivity and the schedules on a project is always a big challenge for a project team due to the complexities involved in taking the decisions fast. In this paper, we attempt to use the “Burndown” information to address this issue. We show in this paper, how a Burndown chart comes in handy when a Project team is faced with the tough questions on the issues pertaining to Schedule Compressions, Resource Management and Productivity Enhancement. As a part of this effort, we also extend the usage of the Burndown charts from the team level to the individual level. Starting with a brief introduction in section 1, the paper proceeds with a quick definition of the Burndown charts, and then presents our approach towards their analysis and the usage in the productivity and the schedule management activities.
The primary objective of this paper is to help the project teams identify the imbalances & discrepancies in the workloads and the productivity variance within a project team and suggest a method to use schedule management techniques to address the issues.
Variance analysis pertaining to productivity and schedules is one of the important issues the project teams address very frequently. It would be of a great help to define an effective approach towards productivity and schedule management activities so that the teams make sure they take necessary corrective actions to meet various expectations on the project. In this article, we attempt to use the concept of the Burndown charts, of the Scrum world [ ] to address the productivity and the schedule management issues. While Section 2 gives a brief overview on the Burndown charts, chapter 3 presents our approach towards Burndown analysis and chapter 4, its usage for productivity and schedule management before the concluding remarks in chapter 5.
The Burn-down chart is a prized gift to the project teams from the agile world. Being a widely used artifact in the current-day scrum initiatives, a Burn-down chart graphically depicts the amount of effort remaining on the assigned work (1,2). When updated daily, this burn-down chart gives extensive information about the estimates and their accuracy, productivity, process control and much more – all the is needed is some effective analysis of these simple charts.
Having said it, the concept of the Burndown charts need not be conceived as only that “of the agile”, “by the agile” and “for the agile” stuff. It can be applied on any project and it would be very effective even in iterative environments after necessary tailoring.
Burndown Analysis – A new perspective
Consider the following Burndown chart for a sprint (Fig. 1)
Looking at it, one may be immediately tempted to conclude that it represents a reasonably well-managed and controlled iteration/sprint that met its productivity expectations. But it may not give the correct picture in all situations. The reason is simple - the above Burndown presents the "Team Perspective" - which essentially means that a team member who is ahead of his schedules levels out with the slower team member. While there may not be an immediate threat for the team, it is definitely a potential hazard for the team in the longer run. After all, every project team aims to work at the optimized levels of efficiency and it expects all the team members to produce their best.
To explain this further, breaking away from the tradition, we have taken the burndown charts to the individual levels by representing the burndown information of the individual team members. The burndown information is presented in Fig. 2) – As it is clearly visible, the variations of the individual burn-downs from the mean burn-down are large and it is not a good sign for the maturity of the process. The scrum master would obviously be worried at this scenario and would immediately call for a meeting focusing on the causal analysis.
Productivity Variance Analysis
Nowhere in the world, would a project team get resources, all with identical capabilities. It is a well-accepted fact the human resources vary in their productivity levels and the teams decide their schedules relying on the varying productivity levels of the individual team members.
The Scrum teams do use the daily standup meetings to discuss the impediments and potential risks, but the meetings stop at that. They just bring the problems out into the open and it is up to the project teams to take decisions. Even to identify the problems pertaining to workloads, the team will have to distill a lot of project data items either manually or using a tool (for instance, the tool Rally®, a trademark of Rally Software Development Corp, provides a facility to examine the individual workloads). For better visibility, we use the Burndown information pertaining to the individual team members to identify the load and the productivity variance. The rest of the section is dedicated to that discussion.
The chart in Fig. 2 gives us a lot of information. It is quite obvious that Adam, probably fresh out of the college, has a problem with his productivity and is struggling to accomplish his tasks. In fact, it could not complete the assigned work in any of the sprints. On the other hand, Vivian, a veteran, has been working at unbelievable productivity levels and has always been completing the tasks, always ahead of time. Unfortunately, in this case, Vivian’s idle time cannot be utilized probably because of the dependencies on Jimmy’s and Sandeep’s tasks. This information will enable the Scrum team to plan the activities better in the next iteration/sprint to optimize the team’s overall productivity. While the standup meeting on the Day 5 would reveal the situation to the team, the burndown chart will help the team get the big picture
Consider the following chart (Fig. 3)
This figure also depicts ideal burndown. On any day, the variance between the average and the ideal Burndown represents how much the team is drifting away from the ideal path. Based on this, the difference between the ideal and the actual productivities can be easily calculated. Extending the same concept to individual Burndown information, one would be able to calculate the variance amongst the expected, average and the actual levels of individual productivity. This will enable the team or the Scrum team to take immediate and effective corrective actions.
Can the Burndown charts assist the Scrum team in schedule management?
Yes, and here is how - although some of the Scrum practitioners don’t like the idea of any changes to the team half way through a sprint, an approach tailored enough to accommodate such a provision adds more agility to the project. Consider the following chart pertaining to the same team, but on a different project (Fig. 4)
The team is half way through an important 4-week iteration/sprint preceding a crucial release. At this point of time, Vivian and Jimmy are cruising along nicely, Adam and Sandeep have problems with their Burndown. At this rate, it is unlikely that they will be able to finish their tasks before the release and hence it is essential to engage in some schedule management activities and this scenario is similar to a schedule compression case.
We see that Adam needs to burn 100 hours in 10 remaining days whereas Sandeep needs to burn 180 hours. Also, Adam’s Burndown rate has been uniform whereas in Sandeep’s case, there is a steep rise on day 6. In the first case, Adam may be asked to work overtime to finish off his tasks (Crashing) 3 and in the latter case, as we cannot expect Sandeep to put in 18 hours a day, the team is expected to rope in additional resources and parallelize the tasks (Fast-Tracking) 3 to complete the work on time (we assume in this example that the tasks can be parallelized) .
To make this a little simpler, we define two alerts for the team which would serve as the thresholds for decision making. With an assumption that a team member can put in a maximum of 12 hours a day during emergency situations for optimal productivity, we define AlertC as an alert that is triggered when the quantity [remaining hours / remaining days] exceeds 8 for an individual, which signals the necessity to crash the schedule. We also define AlertF as an alert that is triggered when [remaining hours / remaining days] exceeds 12 for an individual, which signals the need for Fast-Tracking, in case of the tasks that can be parallelized. In the above example, AlertC is triggered for Adam and AlertF is triggered for Sandeep.
In this paper, we present a way to analyze the Burndown charts to calculate productivity variance (there by leading to necessary corrective actions) and an approach for the decision making pertaining to schedule management using the Burndown analysis. We conclude that the two alerts we have defined viz., AlertC and AlertF can be used effectively for the latter purpose. This approach can be applied to both the Scrum and the Iterative environments. The future work in this area may include extending this concept to Risk, Time and Cost KPAs.
How does this approach make a difference?
· Helps identify the productivity or load variance very quickly using the Burndown charts
· Takes off from where the standup meetings stop and helps the team take schedule related decisions. It even provides inputs to the standup meetings with a high visibility.
· Generates alerts the moment things go out of control, thus helping the project teams take decisions on time.
· Builds a bridge between the PMI and Scrum frameworks.
1. Agile Project Management with Scrum by Ken Schwaber: Microsoft Press, 2007.
2. Scrum Master Training Course Material by the Scrum Trainer Douglas E. Shimp, CST: www.3back.com
3. The Project management Book of Knowledge: Project Management Institute (PMI), 3rd edition, 2004
Not sold on the concept.
In your scenario all tasks are pre-assigned to team members, so this situation can occur. Ideally if tasks are pre-assigned, the team should adjust tasks (to the degree it is technically possible) throughout the Sprint based on individual progress, or let the team members select tasks as the Sprint progresses instead of pre-assigning.
I can see a potential benefit if I have a very dynamic team environment (or just beginning with an entirely new set of team members) and I don’t have a sense of the team’s individual capabilities, but in balance I risk doing more harm then good to the team by continuing to emphasize individual performance vs team performance. The longer I push individual performance the longer I sustain their muscle memory.
I’m not sold on the concept.
Trace Analyst - BurnUp Charts
But we like them a lot - we even wrote a product to produce them. Our technique is to produce burn-down charts by linking planned test cases to passing test cases. That way you have an objective measurement about whether or not a task is completed rather than a vague estimate of number of hour to complete a task. A test case either passes or it doesn't. Sure that still means we have an "estimate" in the form of number of planned test cases, but in practice we find we are able to estimate that much more accurately than time left to complete a task.
Trace Analyst connects requirements/features from JIRA/Excel to JUnit/Excel(manual) based test cases and runs from Ant/Maven to produce HTML/XML/Excel reports. There's also a Bamboo plugin and a Hudson one under development. You can find out more at www.traceanalyst.com
Re: Not sold on the concept.
Adam is fresh out of college, the team during Sprint Planning should understand Adam’s limitations and not assign the same stringent set of tasks to the “fresher” that are assigned to Vivian the seasoned professional.
Two things here - First the tasks might have been assigned, even while they should not have been. So, it is a problem with the planning process and the chart brings the problem out in the open. If this happens to be the last sprint of a release and there is a necessity to wind the things up at any cost, it will allow Vivian to volunteer to take some of Adam's tasks.
Even if Adam receives a heavy load on a Sprint and falls behind, the Retrospective should identify this issue to the entire team to allow corrective behavior in the next Sprint.
Do we want to wait until the retrospective when we have a chance to take corrective actions earlier?
Ideally if tasks are pre-assigned, the team should adjust tasks (to the degree it is technically possible) throughout the Sprint based on individual progress
I agree 100% and this chart gives a chance to have a look at the state of the sprint and adjust the tasks. Doesnt it? And yes, I am not saying that the tasks are preassigned to the team members by some authority. It can as well be a case where the team members volunteer to take the tasks up and one of them lands in trouble with respect to teh load, a relatively free team member can take it up. It goes the same way we adjust the tasks looking at the team status on a tool like Rally
by continuing to emphasize individual performance vs team performance
No, No!!!!! Performance is not at all an issue here. We aint judging no one. All we have here is case where a specific member in trouble leading to a problem with the schedule - and another member who is relatively free volunteers to help the other member out! TEAM WORK!!
We did talk about this before too. How are you by the way?
Re: Trace Analyst - BurnUp Charts
You were spot on when you spoke about the tasks that appear to have moved into the accepted state in the last minute. We do track the number points that get accepted throughout the sprint and we consider the early acceptance of the user stories a good sign. We also try our best to avoid the stories with a large size (by breaking them into smaller stories - our current threshold is 5, in terms of points) so that we can get the acceptance earlier.
Re: Not sold on the concept.
Back to Command and Control
Also, what about communication? If this is a true agile team then Adam would ask for help and Vivian would be happy to do so.
Re: Back to Command and Control
I dont deny, but should it stop us from being proactive in addressing a current problem. We know that there is an issue, we know there is a way to resolve it - why don't we go address it instead of hiding ourselves in the averages? Does it hurt the team if we resolve it earlier than what the playbook says? I dont mean to be pushy out here, but just am curious to understand what stops an agile team to address a problem earlier.
Also, what about communication? If this is a true agile team then Adam would ask for help and Vivian would be happy to do so.
I dont deny again. But does it stop Vivian ( or the Scrum Master) from detecting the problem and proactively volunteering to help? There could be cases (sometimes) where ones problems are detected earlier by the others.
I am not at all professing command and control mode here. I am just suggesting that we can use a mechanism to detect and resolve the problems early.
Okay, say take a single burndown for the entire team and then the team fails to meet the commitment. Don't we discuss that in the retrospective and during the course of that discussion dont we talk about the impediments that made Adam fall behind? In a true agile team, Adam himself would say that he fell behind and there could be a scope for improvement. So, instead of doing that after the fact, why can't we address in during the Sprint whenever possible?
The mechanisms of Scrum solve this problem
1. You try to solve a problem that is being solved by the scrum framework itself - the taskboard and the daily scrum meeting are the alerts you already have in place! Self organizing teams are core to Scrum. Members of self-organizing teams a) help themselves out when one of them is having an impediment and seem to have higher "workload" - as already commented and b) they detect this during the daily scrum. If Adam is experiencing problems other team members will be there to help him, because the whole team has committed to the story.
2. The root cause of the problem you are trying to solve is pre-assigning tasks. Scrum clearly says that teams should not do that. Even in the sprint there is a pull system (tasks) and the team works story by story - all together (hence the name "the-whole-team") - yes some tasks can only be done by some people, but there is always a way to find help by somebody else on a particular task. So there can only be one line in the burn-down chart and that's the remaining work for the team.
3. Measuring individual performance breaks the ideas of the self-organizing team. It is in the retrospective where you think about how to become better (as a team) - an ongoing process. You do not hide anything in the retro - you address it by looking for improvements. And you use the daily scrum meeting to detect problems immediately and there's a role and person who addresses it (ScrumMaster).
Finally, I don't like the word 'workload' (with the individual) - because the velocity, the stories "DONE" by the team at the end of the sprint is an outcome. It is the result when the team has worked with a sustainable pace and highest-quality-attitude on the stories they have committed. So in my world there is no such thing like a task-level schedule, just a bunch of tasks remaining to do and the sprint burn-down is THE tool to show you how you are doing. Inspect and Adapt in the daily scrum.
Within the Scrum community there are newer ideas that improve on these issues and have been broadly accepted, such as don't estimate tasks, just have them smaller than one day per person (or pair if you are doing pairing) and burn down the number of remaining tasks. Or even only plot remaining #points of the undone stories on the taskboard.
Re: The mechanisms of Scrum solve this problem
We knew that people would tend to disagree, but nevertheless wanted to bring it up for a discussion. (Thanks InfoQ)
1. I agree with you - all I am trying to provide in this context is some additional visibility and specifics that dont hurt. When the Burndown gets updated at the end of the day and the team walks in for the stand up the next day, they have this chart available to them to have a look at.
2. This situation might arise even when you dont pre-assign tasks. When you don't pre-assign tasks, the variant here would be the set of "No-Owner" tasks represented on the burndown as "To do". Correct me if I am wrong, I dont see any harm in having multiple burndowns unless we use that to assess individual performace and try to be judgemental about it. Even a tool like Rally gives out the information about the individual loads.
3. Yes, I agree again, but my question was - Do we need to wait until the retro and address a problem that is clearly visible? What does the team lose if the problem is addressed during the sprint (more so if the sprint happens to be the last sprint during a release)?
As of the word "Workload" - I should have used a better term.
It's About the Team; Not the Individuals
We should be measuring the team, as a team. Measuring individuals creates non-team behavior, inter-team competition, etc. The stand-up is where these issues are addressed, and informally within the team.
Remember, we want to move away from Command-Control towards Leadership-Collaboration.. That means this kind of measure is counter-productive.
Reverting to 1980s thinking
I was relieved and very pleased to see the comments from readers.
Top 10 Java Performance ProblemsAppDynamics