Abstract
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.
Introduction
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.
Burn-Down Charts
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.
Conclusions
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.
References
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
