Whether a project is effectively agile or not has a lot to do with the way in which it is planned. Here are three tips that will help you get there: Avoid spending scarce project resources too early on detailed plans that will change anyway, use re-planning as a tool to manage and actively steer the project, not as a fire extinguisher. Plan in self-contained units-of-functionality that can be reordered or replaced cheaply as the project develops.

The three main goals of your planning effort should be to maximize the value of the project for the customer, to ensure that the prioritization is driven by business needs and not by technical solutions, and to make constant change feasible.

Overview

At Iteray, we plan and manage projects according to this straightforward model:

• All projects start with a Discovery Phase. During this phase a team consisting of both the customer, the end-users, and the developers capture high-level requirements in user stories. These are nontechnical plain text descriptions of how users accomplishes tasks with the system.
• Near the end of the Discovery Phrase, the stories are estimated and prioritized and then organized into a release plan which defines their order of implementation. Each release is partitioned into one or more 2 – 4 week long iterations.
• Each iteration is kicked off by a short planning session where estimates and story selections are refined (if necessary). Once this plan tuning is over, the plan is frozen for the duration of the iteration in order to give the developers a stable target. 
• When an iteration is about to end the customer carries out an acceptance test and verifies that each story is implemented as intended. This provides everyone on the project with a clear understanding of the current project status and produces valuable feedback to the developers.
• The project ends when there are no more stories left.

Details, details

Let’s dive into more details. The project starts with a Discovery Phase lasting two or three weeks (see the diagram below). During this phase we work together with the customer and end-users to define the project and write the first set of user stories. These are then estimated (by the developers) and prioritized (by the customer), and then placed into an initial release plan. The release plan shows how we intend to complete the project step-by-step by developing and releasing a number of intermediate versions, each marking an important milestone for the project. Each of these releases is implemented in a number of iterations lasting two to four weeks. Once this initial planning is complete you will have a good handle on how the project will be realized, at what cost, and in what timeframe.

A projects is planned as a series of releases, each consisting of one or more iterations.

This is also where you can make a decision not to go ahead with the project at all, perhaps because it ended up being too expensive to achieve the functionality you need. You may also decide to trim the project by rejecting less important stories or rewriting others until you achieve a suitable balance between cost, functionality, and time.

Stories should be assigned to iterations in a most-important-first fashion. This simple strategy will provide you with a system in which all essential functionality is working as soon as possible, providing you with more freedom for cutting the project short and still walk away with a useful result or starting end-user training or a pilot early. The strategy also ensures that there is time to refine or change the most critical parts of the system, perhaps in response to early end-user feedback.

User Stories

The system requirements are captured in user stories. Each story describes a particular interaction with the system. It doesn’t need to capture every little detail but should instead focus on the essence. Eventually, each user story will be reviewed by the developers before it is implemented and if needed clarified by the customer. In a way, stories are the promise of and foundation for a future dialog about the specific functionality it describes.

User stories must be written in plain English and must not require any technical insight or special training to be readable. Without this requirement, they loose their function as effective and inspiring communication tools shared by both developers, the customer, and the users.

This loose and informal way of capturing requirements is very different from the requirements gathering work used by most other software development methods, many of which demand that requirements are entered into formal documents which are often difficult to read and write. There is a certain irony in the fact that the less ambiguous and more detailed a certain feature is described, the harder it is to understand and get right. Another problem with many highly formalized ways of writing system requirements is that they — by their very nature — are difficult to read for the uninitiated. This makes it difficult for users and customers to participate in the requirements gathering process on an equal footing with the developers, skewing the process and making it much less likely that the customer receives the right system.

You might well argue that the user stories are going to leave out many details and nuances which are important for the finished system. That is OK since one of the cornerstones of the agile planning process is its built-in support for constant change and evolving plans. We only need to get the most important aspects right — the nitty-gritty details are tackled as we move forward.

As the customer or end-user, you’re the one with the deep business understanding. You know what   functionality and behavior the system needs to have to be meaningful. This knowledge makes you the most competent story writer on the team, and it’s why we believe you should be their primary author. We will help you, of course, and we will provide feedback especially when it comes to finding ways in which technology can help you or your users accomplish their goals easier. But at the end of the day, you are the domain expert.

Once the stories have been written, they must be estimated. This is one of our fields of expertise; we know what needs to be developed to realize a given story. That is why the estimation effort is handled almost entirely by the development team.

With the estimates in hand you can prioritize all the user stories and thereby provide the sequence in which they should be implemented (most important ones first).

Iterations

Each release is implemented in a series of iterations. In our experience, the ideal iteration length is somewhere in the range of two to four weeks, depending on the project and the participants. Shorter iterations result in too much time spent on iteration planning and acceptance testing, and longer iterations don’t provide feedback often enough.

As you may have guessed by now, we try not to plan too far ahead in any significant details. In that way we avoid wasting precious resources on developing a plan that — in all likelihood — is going to change considerably anyway. That is why the initial release plan laid down during the discovery phase doesn’t try to get every future iteration exactly right. We prefer to postpone the detailed iteration planning to just before we need it — right before the iteration starts. Just ahead of each iteration we hold a short planning session where we refine estimates and perhaps adjust the selection of stories. 

This planning session is your chance to make any necessary course corrections for the project and make sure it is still on target to deliver the solution you require. By replacing some of the original stories waiting to be implemented with new ones, you can even steer the project in a new direction and respond to changing market conditions, changing resource constraints, or an improved understanding of the problem domain itself.

To provide the developers with a steady target at which to aim, you should only change the plan at these iteration planning sessions and never midway. 

Iterations end with an acceptance testing during which you work through the iteration stories and determine whether they function as intended. If not, the necessary corrections can be worked into the plan for the following iteration.