He who fails to plan, plans to fail.
A good plan today is better than a perfect plan tomorrow.
One of the fundamental Agile values is, "We value responding to change over following a plan," which has sometimes been misinterpreted to mean that we don’t need to plan an Agile project.
Nothing could be further from the truth.
The reality is that on adaptive Agile projects, we do much more planning than on predictive projects (Waterfall), as we plan to accommodate the changes that we are certain will arise. Adaptive project environments are characterized by uncertainty in a number of areas.
While every project needs absolutely clear goals and objectives, the detailed requirements that need to be implemented to achieve those goals are probably not well understood in advance and are likely to change over the life of the project.
Understanding of the problem domain
We accept that our understanding cannot be complete and that the initial vision of the solution needs to be able to change as we learn more about the realities of the problem area.
Rate of delivery
Adaptive projects are largely creative in nature, the teams are trying to solve problems whose solutions may not be readily understood up front, and producing the solutions requires invention. Individuals are not interchangeable, and productivity is not consistent across individuals.
Adaptive projects require an adaptive approach to development that allows the product to evolve as our understanding unfolds over the life of the project. The iterative and incremental way of working on Agile projects provides the needed feedback mechanism for delivering adaptive projects.
Despite the adaptive nature of the Agile project ecosystem, it is reasonable and realistic that management will ask, "How much will this cost and how long will it take?" Organizational resources need to be allocated to the project and decisions need to be made about what work to undertake. This means we need to provide feedback at a number of levels to answer the initial set of questions and on an ongoing basis throughout the project to ensure that we're still delivering the best value for our organization's investment.
To achieve this, we need to plan on many levels. There are two broad categories in which planning happens:
The highest level of planning happens almost completely outside the team, and this is selecting which initiatives should be funded -- doing the right work.
Once a project has passed the "should we do this?" filter, we need to focus on doing the work right
. This is where the five levels of planning on a project come in.
In this article, I will discuss my experiments with doing the work right
First conversation with the client
Often when I start coaching clients, the first question brings up concerns about how to implement Agile (Scrum) for large-scale development efforts spanning across years. In the spirit of Scrum being a framework of Agile, I often talk about the five levels of Agile planning:
I personally like these five levels because they allow flexibility in how you and the organization want to implement planning, based on your teams, environment, and culture.
The 5 levels
The product vision is the point where we move from governance and organization-wide strategic decision making to tactical delivery of products, which results in changes to the way people in the organization work.
The product vision is a crucial tool that needs to convey to the team why they are working, what they are working on, and what key constraints they must work within.
A rule of thumb for product vision is that it is something that helps stakeholders pass the elevator test -- the ability to explain the project to someone within two minutes. It comes from Geoffrey Moore's book Crossing the Chasm
. It follows the form:
For (target customer), who (statement of the need or opportunity), the (product name) is a (product category) that (key benefit, compelling reason to buy). Unlike (primary competitive alternative), our product (statement of primary differentiation).
Here's an example: For the software startup-to-midsize company, who needs a simple, intuitive Agile project management tool, XYZ is a cloud- and mobile-based offering that provides Scrum facilitation, Agile metrics, reporting, and low administrative overhead via social log-ins. Unlike similar services or package software products, our product provides offline capability with peer-to-peer screen sharing and competitive cost.
Product road map
The product road map is a list of the key features and characteristics that the product will need to deliver in order to achieve the vision. The product road map is important when the project spans a number of releases of the product. If there is only a single release, then the product road map and the release plan could be the same thing.
The product road map is a time-based view of the anticipated delivery life cycle of the product. It is a high-level plan maintained by the product owner and project manager that is expected to change over time.
Creating a product road map is a process that can be broken into four logical steps:
Identifying your Agile product requirements
Arranging Agile product features into themes
Estimating and ordering the Agile product's features
Determining high-level Agile time frames
A release is what the name implies: a set of product increments that is released to the (internal) customer. Characteristics of a release are:
Releases are defined by date, theme, and planned feature set. Release dates can be linked to events, such as conferences or changes in the legal system.
Scope, not date or quality, is the variable, which highlights the need to use a prioritized product backlog as the basis of a planning event. When a release date is set in stone, and an increase in budget is unlikely and usually has no positive effect on a release, the scope is the only variable that can make or break the release date.
All teams should commit to the same rhythm of iterations. When all teams work to the same rhythm, the discovery and management of dependencies occurs automatically during the planning activities.
There are fixed release dates across all teams of the program. A typical interval would be two to four months.
Each sprint begins with a two-part sprint planning meeting. Part one of the sprint planning meeting is a review of the product backlog. This is the time for the product owner to describe what he/she wants to see built for the next sprint. During this part of the meeting, it is not uncommon for the team to ask clarifying questions to drive away ambiguity. By the end of the first part of sprint planning, the team will select a sprint goal: a one-sentence description of the overall outcome of the sprint. During part two of the sprint planning meeting, the team decides how the work will be done. In this meeting the team will begin decomposing the product backlog items into work tasks and estimating these in hours. The output of the second planning meeting will be the sprint backlog.
The Daily Scrum or stand-up meeting is an important part of a sprint. A good daily stand-up energizes the team and keeps the project on target. Each member updates the team on three points: what they worked on since the last meeting, what they are going to work on today, and whether they are blocked. The ScrumMaster facilitates and helps address blockers to ensure the overall release is on track.
Implementing the 5 levels of Agile planning
For a client in insurance, we implemented the concept of one chief product owner and several team product owners for this particular program. The chief product owner owned the overall product vision and road map. He updated the product vision every year and the road map every six months. Our releases were quarterly. Leading up to the quarterly release planning event, the chief product owner and team product owners would meet once a week to discuss the program backlog. They worked together to prioritize the program backlog and then disseminate the backlog items to the respective team product backlogs. To help understand technically which team would do what story, occasionally dev team members would attend the product owner meetings to shed light on technical dependencies and challenges.
Once the stories were disseminated into the team backlogs, the teams would start to groom the stories during their backlog grooming sessions and point out unknowns/external dependencies. Then at the all-day, offsite release planning event, each product owner would present his or her team’s stories (at a high level) for the next release and identify external dependencies if they were not known before the release planning. Themes would get reprioritized (if needed) after the read-out, and then all teams would participate in the Fist of Five to show their confidence level in meeting the release goals. From there, the stories would be put into sprints and tracked via the daily stand-up meetings.
In preparing for battle I have always found that plans are useless, but planning is indispensable.
-- Dwight David Eisenhower
There are different ways to implement the five levels of Agile planning, and you, your teams, and your organization need to find the best practices for your situation. Planning pervades Agile projects -- simple tools and safe environments support adaptive planning and honest reporting, which means progress is reported truthfully and management has the information needed to make good decisions that enable the delivery of the best outcomes for the organization, team, and project.
Agile planning takes into account that systems development is undertaken in complex and often unpredictable environments and that flexibility and the ability to respond to change are paramount.