To many people, working in an agile manner means little or no planning, or planning at the last possible moment (e.g., writing user stories for the upcoming iteration during the iteration planning meeting). While this may work in a very small project with a close-knit, highly effective team, for larger projects, it becomes problematic.

Contrary to popular belief, agile projects require as much planning as any other project type. It is the timing of this planning and how we attempt to minimize wasted effort that is different from other approaches. This article attempts to explain the different levels of agile planning and how we utilize them in an ongoing project.

All projects have different levels of requirements, represented in various forms depending on the type of project approach we take. These levels of planning are typically exclusive events involving different people. However, we must ensure that knowledge flows from one level to another (and back again) as seamlessly as possible, or else the intent of the solution can easily be lost or misunderstood.

We start with looking at the big picture through project planning. Note that this is different from the formal project plan you may be used to that is an artifact of the project management office.

The First Level of Planning: Project Vision

This is the highest level of requirement possible and describes, in quite broad terms, what business problem the project is trying to solve. This is primarily undertaken by the business stakeholders, but they must collaborate with the technology organization to help ensure the necessary technology, skills, and people are available.

The project description or vision may be “Increase sales through our e-commerce platform,” “Replatform our ERP solution,” or an example I will use throughout this article, “Sell airplane tickets through a new website.”

The vision should be measurable; this is how we will determine the return on investment (ROI) of the project and define whether the project is successful. This helps ensure our investment in the new project is less than the results of the project, for those projects looking for a positive ROI. Other projects may measure their success by different criteria, such as whether it complies with government regulations or achieves cost savings through reduction in manpower.

The people involved in this level of planning are typically the executive sponsor, product management, executive leadership, and senior technical staff, including technical and business architects, business solution designers, and similar leaders from the business and technical organizations.

In addition to defining the vision, I like to determine what success looks like, using meaningful, measurable terms. I choose two or three items to measure that really display the value of the project. It may well be that the technology project team building this solution has no control over these metrics—rather, we use these as a benchmark for how well the business makes decisions and in helping the business determine when we reach “good enough” in this project.

These success metrics need to answer several questions:

• What am I going to measure?

Be very specific here: annual revenue, number of uses signing up for our service, getting off the mainframe, etc.

• How will it be measured?

Again, specifics are necessary. If this is a financial metric, it should be easy to accomplish, but if, for example, it is something like “getting off the mainframe,” do you measure cycles used to run the code you are replacing, by storage used, or something else?

• What is the benchmark for this metric?

That is, what is the status right now? Is revenue at $1.7 million with a conversion rate to purchase at 8 percent? We need to know where we are starting from so we can determine when we achieve success.

• What is the target result?

When this project is successful, what will this metric reflect? Moving our revenue to $3.4 million? Increasing our conversion rate to 10 percent? If we do not meet our goal, is there a lower threshold that is still a reasonable success? For example, if we increase our revenue to $2.8 million, that might be acceptable, but not as big a success as we would have liked.

This is where we start to break out what we want our project to actually do, albeit at a very high level. Once again, the business is the primary driver for this, but in collaboration with the technology organization. Sometimes our project has only one business capability, but this is rare and indicative of a very small (meaning two or three short iterations to implement) project.

Typically, there are many business capabilities within a project. To continue the example above with the airline, these capabilities might be “Buy tickets online,” “Search for flights between two airports,” and “Manage my frequent flyer account online.”

During the identification of these capabilities, we also need to start identifying risks and determining if there is a base-level architecture. These elements allow us to consider the constraints the project may operate under, allowing us to make better informed decisions as we progress.

I like to take a deliberate, step-by-step approach to getting to stories, and breaking business capabilities into smaller pieces is how. I use the term “theme” to describe big stuff: things that need breaking into smaller pieces of functionality. Consequently, we capture this initial functionality and use it later to refine the overall project definition and direction.

Themes and features are further details about each capability, adding to our knowledge of what the end solution should look like. This is where the business and technology organization really start to collaborate on the content of the solution. While themes are primarily driven by the business, technology has a lot to say about current features, technical capabilities to deliver, and so forth. We want to ensure our investment is appropriate, so both the cost and value side of each theme needs to be considered. These themes must be prioritized to ensure we are delivering value to the business. It is frequently useful to develop themes by understanding who will be using the solution through a technique called “personas.”

In our example, some themes we may want to develop could be “Enter the airport code of departure and the airport code of arrival and determine the fastest route,” “Accept credit card payment,” “Display the cost of the flight selected,” “View my points balance,” and “Allow seat self-selection.”

Initial planning of the project should go no further than this, as we now need to engage the build team (developers, analysts, QA, etc.) in understanding what needs to be developed and how we are going to approach it. This should be done in release planning, which is the next set of activities.

It is useful to estimate at this level using the agile points approach. This type of estimating lets us focus on relative difficulty, complexity, and time expectation between each theme and should not be used as an indicator of how long we expect each theme to take in development. Rather, we can use this estimate as a trailing indicator, learning from it to set realistic expectations for the development effort. For example, if “Display the cost of the flight selected” and “Determine the fastest route” are each eight-point themes and it takes four iterations to complete “Determine the fastest route,” we should expect “Display the cost of the flight selected” to take four iterations too.

The Second Level of Planning: Release Planning

As we discuss the project and each business objective within the project, we will determine that more functionality is necessary, especially if we look at the solution from the end-users’ perspective.

Release planning is primarily the responsibility of the technology organization, but in collaboration with the business. While we should deliver features in a highest-value-first scheme, this is not always possible, and developing an effective release plan balances the need for new functionality with the need for technology capabilities, infrastructure issues, dependencies, and other concerns.

The first task in a release planning session is to ensure we have the functions necessary for a successful product. Therefore, capturing new functions and refining existing functions is critical at this stage.

Following this initial capture of functionality, we need to prioritize the items. This is often difficult to accomplish because when taken as a whole, each piece of functionality is important. Just talking about the relative importance of functionality will lead to enlightening discussions.

Once we have our prioritized list of features, we can start breaking these into stories. Some will be user stories, and some will probably be technical stories, such as the need for new technical tools, databases, etc. They will be treated in the same manner.

Stories are a further breakdown of each feature into something that can be delivered in a single iteration, so each story should be a single deliverable. For example, if I break down the function “Accept credit card payment,” I could write the following stories:

“Select the flight I want to take”

“Enter Visa card details (number, expiration date, security code)”

“Validate credit card”

“Confirm payment”

“Email payment confirmation to customer”

This also allows the business to determine what direction they want to take for these payments: Do they want to allow American Express? How about PayPal? Or accepting online checks?

By prioritizing the features earlier in the planning process, we spend time on the most important functionality first, detailing the stories we want to deliver first. This is one of the differences in using an agile approach: You focus on what you can deliver soon and do not spend time on the things you may change your mind about. It helps eliminate the distractions—and time pressure—of adding detail to everything we already thought of.

Now that we have a lot of stories for this first set of features, we again need to prioritize these stories so we know where to start and what to focus our efforts on completing.

Once more using our airline example, we wrote stories for Visa, MasterCard, American Express, and PayPal, but through some research we did on our customer base, we know that 68 percent of our customers pay with American Express, 26 percent with Visa, 4 percent with MasterCard, and the remaining 2 percent in some other way. In our first release of this product, would I expend energy (and delay other pieces of functionality) to allow payment by MasterCard? Probably not, but this is a business decision.

Now we need to estimate our stories, once more using the agile approach. By understanding how quickly we can get work done (“velocity”), we can then estimate how much time will be needed to complete the total amount of work in this release. Once we know this, we can start negotiating to remove some functionality if we think this release will take too long, or otherwise adjust expectations of this release.

The Third Level of Planning: Iteration Planning

Iteration planning is the domain of the technical team, but in collaboration with the business. This is where we are able to change direction, introduce new capabilities as stories, reprioritize our work, or even decide if the work done so far is good enough to release early. If we have done the rolling look-ahead planning well (see below), iteration planning should be a very short event.

This is when the entire team has the opportunity to ensure they know what stories are planned to be in the next iteration, estimate whether they have enough understanding to complete them, and identify issues that may inhibit the team from completing all of the work.

The Fourth Level of Planning: Rolling Look-Ahead Planning

For each level of planning outlined above, it is vital that these efforts are not single events, but rather ongoing work that is as much a part of the project as coding and testing. We must keep looking ahead, building on the knowledge we have gained, and getting ready to maximize the value we want to deliver. Consequently, each of the types of planning described above should be undertaken on a regular basis with some cadence to it and should be completed by those responsible for each level of planning.

For example, during each iteration, it is the responsibility of some team members (usually the analysts and ScrumMaster) to determine if the work to be done in the next iteration is sufficiently detailed. We are not prioritizing the stories here; rather, we are deciding if the team knows enough to start work on this story or if more analysis work is needed. This follows the same approach as when writing stories in release planning: write the story, prioritize it, estimate it, etc.

But we also need to ensure that acceptance criteria have been developed for each story. I frequently find it useful for the analyst to work closely with QA in developing the acceptance criteria, both as an aid to their development and as a way of giving QA visibility to what is coming up and allowing them to start developing—or at least thinking about—test plans and approaches for the new stories.

This planning should take place frequently during each iteration as a normal part of the daily workload.

Similarly, during each release, some group of people must be looking ahead to the next release, discovering new requirements or changes in direction and technology and prioritizing these discoveries to maximize value delivery.

And finally, while this project is evolving and being developed, we should consider what opportunities it opens up for the business (or what deficiencies in our business it highlights). We should start planning the next project while this project is in flight.

The Fifth Level of Planning: Daily Stand-Up

The daily stand-up is an opportunity for the entire team to come together and ensure everything is fine (or identify issues). Rather than focusing on what they did yesterday (one of the three questions of a typical stand-up), I prefer team members to tell the team what they plan on doing today and asking for help if they need it. This allows other team members to quickly identify if there is a potential for roadblocks of their work and decide if they have something to add to another team member’s efforts.

You can use this same approach to scale agile to large programs, with several teams, multiple projects (or work streams), and maybe even different time zones. Without planning, you cannot scale. Unfortunately, many people think that if you scale, you cannot plan.

This sounds like a lot of work.

Well, yes, it is. Planning requires discipline, and it is an indicator of project success—not the only indicator, but a significant one. You need to be able to focus on a few things and do them well, rather than taking the more traditional approach: planning everything and being a slave to the plan. Balancing the need to know just enough against the desire to know everything (which we never can) is difficult, but if you follow the outline above, I know you will be off to a good start.