Agile Project Planning

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

Saturday, June 04, 2005

Scrum for iterative development projects

Scrum is a methodology for agile software development that's been around for some time. It's been overshadowed by eXtreme Programming (XP) to some degree, which might be more to do with the choice of names that the merits of the process.

The essence of Scrum is the idea of a Backlog of work which is prioritized, and a Sprint, which is a period during which the development team works on prioritized items from the Backlog.

There are some useful metrics and planning activities also associated (e.g. a weekly "scrum" and a daily standup meeting), but the core is still this idea of prioritization by the stakeholders of the feature backlog and an uninterrupted period of work by the development team.

Scrum seems to be easier to get a handle on than XP, since the rules are less involved. XP focuses on practices that complement one another such that removing one of them tends to increase the project risk. Some of these practices, such as pair programming, are somewhat controversial, and scare away potential practitioners.

Scrum, by contrast, is less involved with the details of the development process, and more with the project planning aspects of a software effort. In my opinion, teams just getting started with an iterative approach to development will be able to grasp Scrum very quickly, and without getting caught up in the arguments that new XP teams frequently deal with (Am I doing XP properly?)

Ultimately, though, Scrum is very compatible with XP development, and the same sort of tools work for both approaches. An XP iteration strongly resembles a Scrum sprint, and the idea of user stories is common between the methods.

Now that the initial hype of agile methods has subsided, and more teams have gained experience with these processes, a mix and match approach may well be the best option for teams that are undecided about which method to adopt.

After all, the whole spirit of agile is to use what works, throw away what doesn't, and to embrace change. Methods aside, if you can get fast feedback in every area of the project, from planning through testing, you're doing agile.

For more on iterative development tools and techniques:

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

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