Often, when I coach clients, there are concerns about how to implement Scrum for large scaled development efforts in their organization because a lot of the content available to the general public is at a single team level – not for scaled teams. In the spirit of Scrum being a framework of Agile, I often talk about the 5 levels of Agile Planning:
- Product Vision
- Product Roadmap
- Release Plan
- Sprint Plan
- Daily Commitment
I personally like these 5 levels of Agile Planning because they give flexibility to how you and the organization want to implement planning, based on your teams, environment, and culture.
In this article, I will first define the 5 levels of agile planning and then describe how I helped to implement it for a client in Silicon Valley.
The 5 Levels
Every product or system you are going to develop needs a vision. This vision will most likely be long term spanning an entire year or many years. The product vision 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)
- For the software startup to midsize company,
- who needs a simple, intuitive agile project management tool,
- Cognosco is a cloud and mobile based offering
- that provides scrum facilitation, agile metrics, reporting, and low admin 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.
Once you define the product vision, it can provide input to the product roadmap. The product roadmap should be updated at least every 6 months by the product owner. The product roadmap is an overall view of the product's requirements and a valuable tool for planning and organizing the journey of product development. The roadmap is used to categorize requirements, to prioritize them, and to determine a timetable for their release. Creating a product roadmap can be broken into 4 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 timeframes
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, like 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 and driving away ambiguity. By the end of sprint planning part one, 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 built. 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 standup energizes the team and keeps the project on target. Each member updates the team on three points: what they worked on, what they are going to work on, and whether they are blocked. The Scrum Master facilitates and helps to address blockers to ensure the overall release is on track.
Implementing the 5 levels of Agile Planning
For a client in Silicon Valley, 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 roadmap. He updated the product vision every year and the roadmap every 6 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 respected team product backlogs. To help understand technically which team would do what story, the product owner meetings from time to time would be attended by dev team members 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 their 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 re-prioritized (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 standup meetings.
There are different ways to implement the 5 levels of Agile Planning and you, your teams, and your organization need to find the best practices for your situation. Sometimes this might result in trying different approaches, collecting empirical data, and evaluating, followed by improving and re-evaluating.