Chapter 9: Agile Planning

Planning an agile, iterative, and incremental project involves many concerns, trade-offs, and judgment calls. In this chapter, we discuss a number of agile planning principles to help you plan (and maintain the plan for) an Agile ICONIX project. These principles are summarized as a top 10 list at the end of the chapter.

Note 

As you’ll learn in this chapter, agile planning is primarily about making a project planning driven rather than plan driven. In many ways, this is the differentiator between an agile and a nonagile project. Plan-driven projects are predictive, whereas planning-driven projects are adaptive.

Why Agile Planning?

Every software project involves change, to a degree. Even a project with a completely stable and well-understood set of requirements (a mythical beast indeed) would likely involve change at the design level, as coding progresses. So, recognizing the fact that change is almost a certainty and putting some practices in place that help to manage this aspect of software development are pretty important, to say the least.

XP’s “planning game” provides some useful pointers on how to plan and track an agile project. In particular, it’s useful to divide work into fine-grained, estimable tasks and then track the time spent on these tasks versus the programmer’s estimates. Over time, you can use this to measure the project’s velocity, which in turn helps to make your planning more accurate.

Balancing Flexibility and Perception

Agile planning in many ways reduces risk, not least of which is the danger that a project gets judged a failure and canceled because upper management felt that it was “running late” (even though it’s delivering much more functionality than was originally scheduled). Agile planning instead places the emphasis on the project itself; its success or failure is judged by whether it is delivering business value to the customer and giving good ROI.

However, agile planning isn’t without its own risks. The most dangerous of these is that the team may lose sight of how upper management happens to perceive the team’s apparent progress. A team delivering good software to its own schedule might be shocked and surprised when upper management, who simply wanted project X to be ready by the 15th, shut the project down because they’re still judging it according to the original promised delivery date.

Here’s another way to look at it: introducing agility doesn’t eliminate real-world constraints. For the most part, a project still needs to be “done” by a specific date.^[1.]

How Agile ICONIX Differs from Other Agile Methods

In terms of planning, Agile ICONIX differs from other agile methods because it takes the approach that you design in detail before you begin coding (at least for the current iteration). It might be argued that this makes Agile ICONIX less agile (depending on your definition of agility), but if the goal of agility is to meet the customer’s “real” (and probably evolving) requirements in a decent timeframe, then doing the right kind of detailed design (as we describe in Chapter 3, and in the mapplet example) actually helps us to achieve this agile goal.

In addition, with ICONIX Process there is a concept of a project being done. There is a definite milestone when you can refer back to the iteration plan and the design, and say, “Right, that’s it—we’ve finished!” That’s not to say that subsequent phases of the project might not be launched, and additional requirements might still be added late in the project, but with Agile ICONIX, the level of completeness of a project is something that can be measured.

Example: Agile Planning in Action

Figure 9-1 shows an example of how a project can be planned out. The list shown in the screenshot is a mixture of functional tasks (feature requests) and defects.

Figure 9-1: Tracking defects and feature requests

Each defect and feature request in the list is assigned a Severity and/or a Priority (Must Have, Should Have, Could Have, or Won’t Have, using DSDM MoSCoW Rules; see www.dsdm.org/en/about/moscow.asp). Each item is also assigned a target Release.

Tip 

It’s important to include defect fixes in a list of deliverables for each release, as defects (or at least the effort put into fixing them) are like features: they can be added to a plan, they take time to fix, they can be prioritized, and (assuming a particular defect isn’t an absolute showstopper) they may be pushed out to a future release. As such, tracking and planning defects is a similar activity to tracking and planning new features.

^[1.]For a satirical look at the “software is never done” mind-set, see Chapter 11 of Extreme Programming Refactored: The Case Against XP.