Burning Down

In a classic waterfall (ie. death march) project, burning down would be that last 20% of the project where 80% of the work gets done. You know. Getting in at 6am, gulping lunch down, staying through the evening with cold pizza as a friend, gulping down caffeine and watching the days roll by all too quickly as the deadline approaches. The team, if they're lucky, makes it barely across the finish line usually by jettisoning things like a life boat with too much on board. Things like quality, features, documentation, anything to make the date. Sometimes it's enough, often it's not.

Been there?

No matter who I talk to regardless of whether they work for a large or small company, use the latest technology or don't, have genius developers or not, everyone seems to suffer this fate in software development. It's been studied exhaustively for decades and people have worked to come up with ever more creative ways to keep things on track. Better requirements, better and more detailed schedules, more tracking, more meetings, more "one more for the Gipper" sessions, and so on. Yet, the problem continues.

Why?

Basically, for a very simple reason. It's really, really, really hard to know everything that needs to be done on a project that takes more than a day or so to do. A day. Not a few months, not even a few weeks. Teams that think that they can, actually rarely do and only then by likely having done the same task before. And this gets to why software is so different from other work - it's always changing and is highly subjective. Designing an entry form for data could be a simple exercise or take weeks of implementation depending on the depth of usability that is desired, the platforms the application must support, the richness of the tools that are used, and so on. So many variables to consider. It's a wonder we've gotten software out at all.

Yet, an Agile project faces this same problem as any other. Scrum's solution to this is the burndown. That is, a way to see what is going on in the project and using that information to do two things - create an awareness within the team of how they are doing on the backlog items they are working on, and secondly, providing information about how much work, or as Scrum refers to it, as Velocity, the team can get done in a given unit of time (the Sprint).

As the team proceeds through the days of the sprint, they spend considerable time thinking, talking and adjusting their assumptions of what work they have left to do for the Sprint. These assumptions are what is detailed in the Sprint Backlog - that is, the set of work that needs to be done to complete the items in the Product Backlog - at any given day. That latter part is critical to understand. Scrum is always looking forward during the Sprint. It's always asking the team "what is left to do", "how much time is remaining for each task that remains", and so on. It does not look backward at how much time has been spent on a work item, whether all of the work items were discovered up front during planning, worry over metrics of estimates vs actuals, and so on.

You need to really, really think deeply about that for a bit. Once you spend time pondering this idea, you get a kind of Eureka! moment with Scrum. The "I get it" moment.

When a team asks me about the Sprint Backlog, they are often hesitant about what they are "allowed" to do to it. My response is the following - the Sprint Backlog is yours. You can do whatever you want with it. The tasks can change at a moment's notice. You can change your remaining hours whenever you wish. You can add, delete, modify and so on anything you wish. And you don't need permission for any of this. Your only requirements are that the Sprint Backlog reflect the team's best guess at remaining work for the Sprint each day, and each work item has a best guess at remaining hours before that item is done.

I usually throw out an example. Say you estimate a work item during the planning session as taking 5 hours. Maybe it's creating a basic data entry form based on the Product Backlog item. You start to work on Monday morning. During the day things don't go well. The tool you selected has issues. You spend the day on the phone with the vendor. You make some progress, but by the time you leave, you realize that this form is going to be harder than you thought. You stare at the remaining hours for a bit and decide that given what you now know, you need 15 hours to finish this task. Think about that for a minute. You thought you needed 5 hours the day before. You spent, say, 8 hours on it. You now think you need 15 hours to finish it.

That's just fine in Scrum. In fact, it's healthy. Because this kind of thing happens all of the time. One of the big ways that I think Scrum can fail for a team is if they start playing games with the tasks and remaining hours. You know, a kind of on-the-books, off-the-books set to keep the "boss" happy. Scrum says, "no way". The Sprint Backlog needs to be as close to what the team thinks is reality on any given day as possible.

And here's why.

As the days proceed, there is a running total of remaining hours of work in the Sprint Backlog. That is, you sum the the hours for each open task and you get a total. Ideally, this total goes down each day through the Sprint until it reaches zero on the last day. Nice linear line.

Never happens.

Actually, I should have said that "stuff" happens. As I mentioned earlier, people discover new work for an existing item, they discover new work items, old work items are closed or deleted, and so on. The sum of remaining hours per day fluctuates and can go up on any given day if new work is discovered. In a classic process model this would be a bad thing and cause meetings to ensue. In Scrum this is just noise in the system. It's tracked and the team monitors it. But work continues.

The trend of remaining hours is called the burndown.

But you probably already guessed that by now.

Next time, I'll talk about what happens if the burndown doesn't burn down fast enough.

Technorati Profile

Posted by Mark M. Baker at 05:14 PM  Permalink