When Fast isn't Fast Enough

Last time I talked about the Agile/Scrum notion of a Burndown. If you haven't read that entry yet, go back and read it top to bottom or the remainder of this entry won't have any perspective for you. At the end of that entry, I mentioned that sometimes a Burndown doesn't happen fast enough; that is, the work that proceeds through the month of the Sprint doesn't go to zero remaining hours (i.e. we're done) quickly enough. Scrum doesn't prevent this from happening, but it does give you tools to manage it, and adapt future Sprints to how much work can get done in a Sprint.

And this is the basis for any good (and realistic) schedule.

Unlike the formal, waterfall-style project management methodologies, Scrum doesn't focus much attention on projecting a schedule based on assumptions of time utilization, productivity, interruptions, and so on. Scrum says that this is basically impossible and is a reason why the vast, vast majority of software projects come in late or not at all. Essentially, in a formal approach you are trying to itemize every conceivable thing that could interrupt the work flow, weeks or months in advance, and setting an end date based on those assumptions.

So what happens if during a given work month, the team runs into problems with some 3rd party technology that seemed to work so well in the demo's? Or the team gets bogged down in the design of the user interface? Or team members get sick from that nasty virus making its way around the company? And on, and on, and on.

Answer: your schedule slips. Actually, the reality from Scrum's perspective is that your gloriously detailed schedule is probably slipping as soon as you hit Save and printed out a copy to hang on the wall both from anticipated issues that take longer to resolve than expected, and the unanticipated issues that you completely overlooked (gee, that's what a buffer is for, right?)

For most teams, they either work harder, longer or faster, or start cutting corners to make the promised date. In Scrum, this doesn't happen. Let me state that again, in Scrum this doesn't happen.

Huh? Does Scrum have a magic elixir to creating a perfect schedule? Actually, no. Scrum eschews the whole notion of a perfect schedule in favor of a work unit (ie. the time-boxed Sprint) that is organized on the principle of delivering highest business value features first. Scrum says that basically "stuff happens" to re-use a well-worn euphimism. That no one, and I mean no one is smart enough in a software project of any reasonable size to know everything that will ever happen and the time it will take before the software can ship.

More importantly, Scrum says that even if you think you know, you can't because what is knowable at the beginning may not be the same set of facts later on in the project when people change their minds, new priorities emerge, and so on. Strikes me as almost a Quantum Theory of Software Development. Hmm. Where's the cat..

Back to the Sprint now. So, the team is working along on the next set of prioritized business value items from the Product Owner during the month. As they proceed, they continuously update their Sprint Backlog (their ToDo list) and the Remaining Hours of work for each item. In Scrum, we focus on Remaining Hours, not Used Hours, Original Hours, or any other comparison to the past. We only care about how much work is actually left. The total of all of this work is summed per day. This data can then be graphed showing the relationship of work remaining to time. In the ideal world, the line would be perfectly linear. But in the real world, the trend line moves up and down as work is discovered, estimates are changed, work closes more quickly than expected, and so on.

But sometimes a Team finds that they overshot the mark when they agreed to select a certain number of Product Backlog Items during the Planning Meeting. Essentially, they bit off more than they could chew. Even in Scrum, this can happen. It's particularly common when a Team gets started in Scrum for the first time; they have no idea in reality how much work they can get done and often select way more work than they can do.

As the Sprint enters the 3rd week of work, the trendline of the Burndown is likely showing how things will end for the Sprint. If the trendline is not promising (ie. they won't make it), the Team gets with the Product Owner and notifies them that one or more work items won't get done in time for the Sprint. For many teams, and many Product Owners, this is the first real introduction to Scrum and Agile in general. Up to now, it's been nice theory and everyone feels good about the communication aspects. But now we get to see what happens when things don't go so well.

First, the Product Owner is likely to be an unhappy camper. But, that's reality. Yes, the Team could work weekends, nights and exhaust themselves to make the date but in Scrum's way of doing things, this is a very bad thing except in dire situations (like the company is going out of business if we miss the date). The correct approach is an honest discussion between the Team, Product Owner, and Scrum Master about the situation. Often, the work items can be simply moved to the next Sprint. However, if a work item is partially completed, the Team doesn't get to state this at the end of the Sprint; it's either done, or not done. There's no middle ground in Scrum.

Second, the impact of this is that the Team is forced to see that their capacity to do work is less than they thought using their current development practices. During the next planning meeting this information will be used to gauge how much work should be selected again. The challenge for the Team is to select a lesser amount of work for the upcoming Sprint based on this knowledge. In Scrum, this is called the Team's Velocityand is a way of describing the bandwidth of the Team. This is key to predicting how much time it will take to complete the feature set, enhancement list, etc that is expected by the Product Owner.

Next time, I'll talk a bit more about Velocity and why it's so important to Release Planning.

Posted by Mark M. Baker at 03:09 PM  Permalink