Burning Down Not Out

The burn down.   If you haven’t used one for your project before, the concept is easy.  Given a lot of something now, how long will it take to get rid of it all.  Work, hours, tasks, budget allocation, release features…  Agile also had the concept of a burn up…  instead of going to zero we simply flip it so that we will accumulate work over time up to a maximum level of something.  Preference was up to the organization, but sometimes both were kept as a way to instantly recognize what level/scale was referred to.  If one was talking about the progress of a team (burn down) or the progress of a release (burn up).  So much of what we do is empirical.  In other words; it is an observed side-effect of our direct efforts. At times this may not be intuitive.  Scrum uses these charts to point our attention to when is done?  It is not an artificial moment in time that is the focus.  It is our software deliverable we really focus on.  The accumulation/dispersion of effort through consistent units of time is represented in a way which helps us characterize if our capacity for this work is realistic.  By knowing our capacity, we are also dedicated in continuously improving the organization’s ability to do work.  We do all of this through great teams.

A Team Burn down  Scale the y axis in hours, tasks, story points and the unit of choice can affect how the team works.  As a scrum master there are some tools which enable the tracking of hours, and tasks and will display both of these for a team simultaneously.  Typically the lines will track each other very similarly though different in scale.  It is a matter of resolution.  350 hours seems to be a finer resolution than 70 tasks, but what if the team enters updates just every evening?  The maturity of the team also comes into play here.  A shu (Shu – new, Ha – intermediate,  Ri – advanced) team, just coming together may find it easier to talk in hours the first few sprints.  As they get better, and need to look up across the sprint.  A bootstrap out of hours and simply into done tasks is usually better. It is a matter of what I will call transaction distraction.  A better term might even be ‘clutter’.  So many things to put a fine point upon that we sometimes lose sight of the middle and end games. Another way to view it is a ‘level up’ as we master some things and begin to practice a higher level of awareness for things of greater scale.   Some teams prefer to retain the hours perspective as a sanity check when planning the next sprint.  It is another lens through which to assess the risk of the work they are forecasting and committing to.  I will use a task burn down and usually focus a ha team on it when we see some risk to the sprint.  Would a ri team even need tasks?  Perhaps the story pointing may be an accurate enough guide for these experienced veterans. A task-level burn down might consider the following:

  • Tasking. Using the task board, establishes a plan. This is the wall or whiteboard around which the team can hold their daily scrum.  I even had a ‘land locked’ team show creativity and wrap theirs around a column in the middle of their pod!  The teams work this plan and adjust the plan daily.  Visible, active, shared problem solving and swarming.  Many coaches like to say Hold Accountable and there is something to this… I prefer to give it a twist though and say Help Accountable.  Not everyone is good at seeing when they are being distracted, stopped by some problem, or simply need help.  Are we getting better as we get accustom to the interaction or even the technology?    Tasks that come anchored with someone’s hour limit – doesn’t prevent, but can erode the swarming behavior we want to see in our teams.  Especially if the estimate is made from a different skill level.  We are not trading hours equally – but if you grab this task we are at a higher level of trust that one of us has the ball and will run with it.
  • Transactional duplication.  There is overhead or a cost to the number of things we track, the tools we use to fill out certain forms.  If instead there was a very simple rule – that would eliminate just some of our effort… we move that much faster.  If we are at a sustainable pace – aren’t we agreeing to average a 40 hour week?  Do we need to track the hours of every task?… probably not.  Also know that most rules have exceptions.  On the whole, however, we are trying to work at a predictable pace where people won’t burn out.  They also need some time to be able improve processes, tools, and even themselves.
  • Characterize.  This is for the team… I would not show a team burn down in a review… maybe an occasional retrospective though. A team can get desensitized by being shown it every day.  Are you looking deeper though?  A scrum master, at times, is sort of  a team historian.  Would you know the most stories or most tasks we ever took on in a sprint and completed?… these small benchmarks can help to identify when the team has improved, and have an excuse to celebrate a broken record.  For instance – I keep track what the MOST TASKS the team ever completed in one day as a team record. It is a RATE – which does depend on the work.  We assume the work will always change.   How about the average number of task closures per day?  It is to identify risk. How well do they task out stories?  The team will help accept and relay confidence or mitigate and problem solve to bring the sprint in successfully.  It is a reality check against how our team performs.  We ask this of ourselves so that we can characterize the engine, the team, and the severity of the situation.  We want to inform the product owner and the program as soon as possible.
  • Focus.  A scrum master directs the focus of the team.  Remember transaction distraction, there is only so many things we can hold in our attention.   Is it really about the hours, getting the tasks to done, getting the story completed, the sprint goal being achieved, or the working software?  At different times, for different circumstances, it could actually be any of these.  What was the price in order to get there in terms of impact?  We use the burn down to be thought’full’.  To alert ourselves to a severity and to address it calmly in the best manner that suggests itself.  The burn down is a side effect of our work, not a focus.   In other words our work is not done just to satisfy the burn down. It is too easily gamed. No one will yank agile badges here, but we use it with the intent to become better problem solvers.  We want to be able to pull our heads up out of activity every so often to assess the situation critically, be creative, and improve a few things while delivering the software.

A Release burn down

The term ‘Characterize’ is a good one to replicate here as well.  It is the way with which we are assessing the organization’s ability to  deliver work. How well can we share this load across all teams for the most important priorities.  What trade-offs do we have to make for our potentially shippable increment.  This helps us tie everything together at a larger level.  Are we even honest with ourselves for what is complete?  What it doesn’t show may be even more important:  things like dependencies and risks. A burn down is just a tool.  It can be like any tool; useful, misused, or dismissed.