Burndown Analysis for Managing Productivity & Schedules

Under normal circumstances I’d let my team work through any variances in their velocity through their Sprint Planning and Retrospective processes. If as your article suggests, 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. 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.

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.

Our experience with Burn-down charts is that when they are based on developers estimating they time they have left to complete a task then you get a strong effect where everything is "finished" at the last minute. If people are given a task and told they have so many hours to complete it, then they tend to "hoard" any extra hours and so the statistics produced get distorted. What tends to happen is that for the first half of a sprint it looks okay, then for the second half of the sprint it doesn't look like you're going to make it and then in the last few days everything suddenly become "complete".

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

Jim,


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?

Richard,

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.

One more thing. If we dont want to pre-assign the tasks, then there can be one more line on the burndown representing the unassigned or "No owner" stuff. The same logic holds good there, with an expetion that most of the observation/analysis revolves round the unassigned task line.

Where is the agile team aspect in this. Some stories might be tougher than anticipated, others are easier. If the whole team is doing fine then there are no worries. It is the average which counts. Same as for the velocity. Some sprints you make a story worth points less and the next you make more. Average is the great equalizer in agile projects.
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.

If the whole team is doing fine then there are no worries.
__________________________________________________________

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?

I disagree with the points made in your article, because

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.

Andreas

Andreas,

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.





3.

I have to agree with Ralph.

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.

When I read statements like this, I became worried: "...a team member who is ahead of his schedules levels out with the slower team member..."

I was relieved and very pleased to see the comments from readers.

I like the core idea behind this. Although it sounds blasphemous to the pure agilists, it always helps to use this mechanism to track the problems early and resolve them. After all, being Agile means being open to improvements.

Hi, we use Scrum org wide for project management, and its working well compared to waterfall method. As part of company sponsored training, I also got my agile scrum certification Scrum Master Certification recently.

Having worked as a coach for 7 years in this area after the publication of this article, I realize how wrong I was, in presenting this concept. Good learning, nevertheless.