- Chapter 3: An Agile Approach
- An Agile Approach to Planning
- Summary
- Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
An Agile Approach to Planning
Estimating and planning the development of a new product is a daunting task made more difficult by our misconceptions about projects. Macomber (2004) points out that we should not view a project solely as the execution of a series of steps. Instead, it is important that we view a project as rapidly and reliably generating a flow of useful new capabilities and new knowledge. The new capabilities are delivered in the product; the new knowledge is used to make the product the best that it can be.
On an agile project, we use this flow of new capabilities and knowledge to guide the ongoing work. The new knowledge generated by the project may be about the product or the project. New product knowledge helps us know more about what the product should be. New project knowledge is information about the team, the technologies in use, the risks, and so on.
We frequently fail to acknowledge and plan for this new knowledge. Failing to plan to acquire new knowledge leads to plans built on the assumption that we know everything necessary to create an accurate plan. In the world of software development, that is rarely, if ever, the case. Ward Cunningham has said that “it’s more planning what you want to learn, not what it [the product] will be in the end” (Van Schooenderwoert 2004).
I often equate the traditional view of a project as running a 10-kilometer race. You know exactly how far away the finish line is, and your goal is to reach it as quickly as possible. On an an agile project, we don’t know exactly where the finish line is, but we often know we need to get to it or as close as we can by a known date. An agile project is more like a timed race than a 10-kilometer race: run as far as possible in sixty minutes. In this way, the agile project team knows when they will finish but not what they will deliver. When we acknowledge that the result is both somewhat unknown as well as unknowable in advance, planning becomes a process of setting and revising goals that lead to a longer-term objective.
Multiple Levels of Planning
When setting and revising goals, it is important to remember that we cannot see past the horizon and that the accuracy of a plan decreases rapidly the further we attempt to plan beyond where we can see. Suppose you are standing on a small boat and that your eyes are nine feet above the water. The distance to the horizon in this case is slightly over four miles.[1] If you are planning a twenty-mile trip, you should plan on looking ahead at least five times, once every four miles. Because you cannot see past the horizon, you need to look up occasionally and adjust your plan.
A project is at risk if its planning extends well beyond the planner’s horizon and does not include time for the planner to raise her head, look at the new horizon, and make adjustments. A progressive elaboration of the plan is needed. Agile teams achieve this by planning at three distinct horizons. The three horizons are the release, the iteration, and the current day. The relationships among these (and other) planning horizons are illustrated in the planning onion of Figure 3.1.
)
Figure 3.1 The planning onion. Agile teams plan at least at the release, iteration, and day levels.
Most agile teams are concerned only with the three innermost levels of the planning onion. Release planning considers the user stories or themes that will be developed for a new release of a product or system. The goal of release planning is to determine an appropriate answer to the questions of scope, schedule, and resources for a project. Release planning occurs at the start of a project but is not an isolated effort. A good release plan is updated throughout the project (usually at the start of each iteration) so that it always reflects the current expectations about what will be included in the release.
At the next level is iteration planning, which is conducted at the start of each iteration. Based on the work accomplished in the just-finished iteration, the product owner identifies high-priority work the team should address in the new iteration. Because we are looking at a closer horizon than with release planning, the components of the iteration plan can be smaller. During iteration planning, we talk about the tasks that will be needed to transform a feature request into working and tested software.
Finally, there is daily planning. Most agile teams use some form of daily stand-up meeting to coordinate work and synchronize daily efforts. Although it may seem excessive to consider this planning in the formal sense, teams definitely make, assess, and revise their plans during these meetings. During their daily meetings, teams constrain the planning horizon to be no further away than the next day, when they will meet again. Because of this, they focus on the planning of tasks and on coordinating the individual activities that lead up to the completion of a task.
By planning across these three time horizons—release, iteration, and day—agile teams focus on what is visible and important to the plan they are creating.
Outside the concern of most individual agile teams (and this book) are product, portfolio, and strategic planning. Product planning involves a product owner’s looking further ahead than the immediate release and planning for the evolution of the released product or system. Portfolio planning involves the selection of the products that will best implement a vision established through an organization’s strategic planning.
Conditions of Satisfaction
Every project is initiated with a set of objectives. Your current project may be to create the world’s best word processor. Creating the world’s best word processor, however, will typically be only one objective for this project. There will almost certainly be additional objectives regarding schedule, budget, and quality. These objectives can be thought of as the the customer or product owner’s conditions of satisfaction—that is, the criteria that will be used to gauge the success of the project.
Way back when I was in high school and assigned to write a paper about a book such as Moby Dick, I would always ask the teacher how long the paper had to be. She’d respond something like “Five pages,” and then I knew her primary condition of satisfaction. There were, of course, a number of additional, unwritten conditions of satisfaction, such as that the paper would be well written, my own work, in English, and so on.
At the start of release planning, the team and product owner collaboratively explore the product owner’s conditions of satisfaction. These include the usual items—scope, schedule, budget, and quality—although agile teams typically prefer to treat quality as non-negotiable. The team and product owner look for ways to meet all of the conditions of satisfaction. The product owner may, for example, be equally satisfied with a release in five months that includes one set of user stories as with a release a month later that includes additonal user stories.
Sometimes, however, all of the product owner’s conditions of satisfaction cannot be met. The team can build the world’s best word processor, but they cannot build it by next month. When no feasible solution can be found, the conditions of satisfaction must change. Because of this, release planning and exploration of the product owner’s conditions of satisfaction are highly iterative, as illustrated in Figure 3.2.
)
Figure 3.2 Conditions of satisfaction drive both release and iteration planning.
Once a release plan covering approximately the next three to six months is established, it is used as input into the planning of the first iteration. Just as release planning began with consideration of the product owner’s conditions of satisfaction, so does iteration planning. For an iteration, the product owner’s conditions of satisfaction are typically the features she’d like developed next and some high-level tests about each feature.
As an example, consider a travel site that includes the user story “As a user, I want to be able to cancel a reservation.” In discussing this story with the product owner, the developers learn that her conditions of satisfaction for this story include
- A user who cancels more than twenty-four hours in advance gets a complete refund.
- A user who cancels less than twenty-four hours in advance is refunded all but a ﾛ25 cancellation fee.
- A cancellation code is displayed on the site and is emailed to the user.
Like release planning, iteration planning is iterative. The product owner and the team discuss various ways of best meeting the conditions of satisfaction for the iteration.
Feedback loops are shown in Figure 3.2 from the resulting new product increment back into the conditions-of-satisfaction boxes at the start of both release and iteration planning. Based on their experience developing the product increment during the iteration, the team may have gained knowledge or experience that affects planning at one or more of these levels. Similarly, showing the product increment to existing or likely users may generate new knowledge that would cause changes to the plans. An agile team will incorporate these changes into their plans to the extent that they lead to a higher-value product.
Footnotes
[1]To calculate the distance to the horizon in miles, multiply the square root of the height of your eyes by 1.35.