Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Wednesday, June 01, 2005

Why 90% equals 0% for agile projects

"What's the status of the new SuperParser function?" asks your project manager.

"Oh, it's 90% finished, I'm just trying to figure out a few minor issues" you say.

Unfortunately, you've said this every week for the last 3. Before that, it only took you a week to get to so-called 90% completion.

What's wrong with this picture? Are you wrong for thinking you're almost done? Of course not, but that's because your definition of done isn't easy to measure.

In agile projects, done means "integrated, running code that passes all unit and acceptance tests". Percentages of done are completely meaningless in this context. It's done or it isn't. The business can use it or it can't.

To paraphrase Yoda of Star Wars fame, "Done or done not, there is no almost."

One sure way to lose track of project status is to rely on fractional completion of stories as your guide. The key in an agile project is to deliver working, tested features that can be shipped if necessary. The only meaningful measurement is the number of such features that are done as defined by that rule.

Of course, in order to get to milestones, you might look into breaking these stories into more manageable units. Instead of the grand SuperParser feature that reads Egyptian and Sanskrit along with C++ code, maybe split that up into just the basic C parser, then the C++ parser as a separate story. Your project sponsor may decide to eliminate support for Sanskrit after doing more thorough market research.

Being able to get feedback on smaller stories or features is very important, since the less involved a story is, the easier it is to be "done". A good rule of thumb is to keep the estimated size of a story under 40 hours of effort.

So, let's try that question again:

"What's the status of the new SuperParser function?" asks your project manager.

"Well, the C Parser story is completed and ready to ship. The Sanskrit story is giving me some problems, but I think I'm a week away" you say.

Even better, you record your estimates and status in a collaborative tool that the whole team can see, so the PM doesn't even need to bother you every hour. Break your story down into tasks, and estimate those to get an even more accurate sense of timing.

At the end of the day, a story is completed or it's not. 90% = 0% as far as the business is concerned.

For more on agile project management and tools:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • Yes, this is good. But, What happens when 100% is not 100%. I've seen this several times with projects.
    "I've completed the Wizbang feature, so mark that as closed. But, the implementation uses a bubblesort, so at some point we'll need to change that to a quick sort."
    So, how does a PM manage all of the bits and pieces that developers say they'll need to come back to?

    By Anonymous Anonymous, at 9:17 AM  

  • Well, the way I've handled this in the past is to create separate stories like "Optimize Wizbang performance", and assign a priority to them. That way the idea doesn't get lost, but you can defer implementing it until it's needed. What often happens is that you discover you NEVER need the optimization, etc.

    By Anonymous Anonymous, at 10:34 AM  

Post a Comment

<< Home