Experience gathered
during large-scale implementations of agile concepts in software development
projects teaches us that agile methods, like Scrum, do not scale to program,
product and organization levels without change. However, various planning
frameworks have, in fact, been used successfully in large-scale agile projects,
which can broadly be defined as projects that involve over 50 people and take months
or years to complete. One such framework relies on five levels to address
the fundamental planning principles of priorities, estimates, and commitments.
The five levels can be defined as: product vision, product roadmap, release
plan, sprint plan, and daily commitment.
In agile, loading a team
with work is done through iteration planning. For very small projects, it‘s
often sufficient to plan only a single iteration at a time. But when iteration
planning is applied to projects that run for more than a few iterations or
involve multiple teams, the view of longer-term implications can be lost entirely.
View the Webcast
Five Levels of Agile Planning
Date: Tues, June 12 Time:10:00 AM PT / 1:00 PM ET /1800 GMT
In plan-driven and
waterfall methodologies, this problem is overcome through a large upfront
design, aiming to predict accurately how much work is involved in each project
activity. This leads to a large investment early in the project, when it is by
no means certain that the designed functionality is actually desired by the
product owner. Any agile approach to large-scale development has to avoid the
reintroduction of the big design up front. One solution is to add planning
levels to incorporate a view
Advertisement
of ‘the whole.'
Agile planning
activities for large-scale development efforts should rely on five levels:
Product Vision
Product Roadmap
Release Plan
Iteration Plan
Daily Commitment
The certainty of
undertaking activities addressed in each of the five levels increases as the planning horizon reduces from a year, to a
quarter, and then to two weeks (see Figure 1). Therefore, the amount of detail
addressed, the number of people involved, and the frequency of planning and
design activities can increase without running the risk of spending money on
features that may not be built or may be built differently.
Figure 1: Agile planning
activities for large-scale development efforts
Level 1 - Product Visioning
The broadest picture
that a person can paint of the future is the product vision. In this vision,
the product owner explains what an organization or product should look like
after the project finishes. She indicates what parts of the system need to
change (establishing priority) and what efforts can be used to achieve this
goal (establishing estimates and commitments).
How To: Lead a Product
Visioning Exercise
The product vision
describes a desired state that is six months or more in the future. Further
planning activities will detail the vision, and may even divert from the vision
because the future will bring us a changed perspective on the market, the
product, and the required efforts to make the vision reality.
There are several possible
structures for a visioning exercise, two of which are to create an elevator
statement[1]
or a product box.[2] The
principle of both exercises is to create a statement that describes the future
in terms of desired product features, target customers, and key differentiators
from previous or competitive products. Anyone who has gone through Certified
ScrumMaster training is likely familiar with the product visioning exercise.
Level 2 - Product Roadmap
The era of large-scale
projects that deliver results in years is behind us. Customers demand more
frequent changes, and time-to-market is measured in weeks or months. The higher
frequency and smaller timeframes force a product owner into thinking in steps -
into thinking of a road towards the final product. Just like a journey is
planned upfront and shared with fellow travelers, a product roadmap is created
and communicated to fellow delivery people.
The goals for doing so
are for the product owner to:
Communicate the whole.
Determine and communicate when releases are needed.
Determine what functionality is sufficient for each release.
Focus on business value derived from the releases.
The delivery team, on
the other hand, will:
See the whole.
Learn about the steps to realize the vision.
Learn the business priorities.
Provide technical input to the roadmap.
Provide estimates for the projected features.
How To: Develop a
Product Roadmap
The creation of the
roadmap is largely driven by the product owner in a single meeting or a series
of meetings. This can be done, quite literally, through a graphical
representation of the releases, or more formally in a written document
outlining dates, contents, and objectives of the foreseen releases.
In anticipation of the
next planning stage, a list of desired features also needs to be built - this
is the product backlog. In its simplest form, such a backlog is a table or
spreadsheet of brief product requirements, so the delivery team can provide
estimates for delivery of each feature. Because the success of an agile project
depends on the early delivery of the highest priority features, the list must
be prioritized. And because the success of a project is measured in business
terms, the prioritization of the feature list is the responsibility of the business,
i.e. the product owner. Interaction with the delivery teams is required.
Without a discussion of the features it will be hard for the delivery team to
produce estimates that have an acceptable inaccuracy. Characteristics of a
product backlog include:
One product backlog for all teams (see the whole).
Feature priority based on business priorities.
Technology features (sometimes called non-functional features) limited
to those that have direct impact on the success of the product in the market.
Level 3 - Release Planning
In small projects, the
product backlog alone can provide enough project overview. The size, duration
and deliverables are easily recognized, and there is no need to synchronize or
group deliverables or teams. All of this changes when applying agile concepts
to programs. The first moment to start grouping activities and allocating them
to teams occurs during release planning.
A release is what the
name implies: a set of product increments that is released to the customer.
Some characteristics of a release are:
Releases are defined by date, theme, and planned feature set.
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.
All teams must 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 with a
typical interval of two to four months.
Release vs. Iteration
A release is defined at
the system or program level, usually in product owner vocabulary. The release
theme, release date, and prioritized features together form a release as defined
by the product owner. When releases are seen in the perspective of the roadmap,
the highest level of visibility and confidence are in the current and next
release. Near-term releases have more detail in the feature descriptions and have
smaller individual features. A release can stretch over six to nine months,
although two to four months is more common.
An iteration, on the
other hand, is defined at the feature level. The delivery team and product
owner have agreed on the number of iterations in a release. Features delivered
in an iteration are determined by the priority, and the number of features
delivered is set by the velocity of the team and the team estimates of the
features. Iteration lengths vary from one to six weeks, with two weeks as the
most frequent duration.
How To: Conduct Release
Planning
A release planning
session typically takes place over a full day or sometimes two, if the program
is very large (hundreds of team members). All team members participate in the
session, including product owner, full delivery team, and stakeholders. Release
planning should be highly collaborative and interactive. Tools used are
typically sticky notes, flipcharts, and whiteboards, and results will be
managed and communicated in an Agile project management tool. An agenda[3]
for release planning could be:
Introductions, goals, agenda updates.
Product vision explanation by the product owner.
Time-boxes for the releases and iterations.
Capacity calculation by the delivery team.
Agreement of deliverables (when is a feature "Done").
Moving features from the backlog into the iterations within the release
by the individual teams.
Determination of dependencies by walking all the teams through the individual
planning results and moving features to alternative iterations to solve the dependencies
within and between teams.
Final calculation of workload per iteration and comparison with the available
capacity.
Review of discovered risks and issues.
Retrospective of the session.
Level 4 - Iteration Planning
For each iteration
within the release, a planning session takes place to add detail and increase
accuracy. Before or during the session, detail is added to the features by
decomposing them into tasks. The actual capacity of the individual teams is
known with more certainty than during the release planning session. The
combination of these increased accuracies helps the team commit to delivering a
number of features during the iteration with a high degree of certainty.
How To: Plan an Iteration
The structure of the iteration
planning session resembles release planning, with the prime distinction of the
planning horizon - only a single iteration. Although the teams work individually
to produce their iteration plan, synchronization between teams provides an effective
mechanism to detect and resolve dependencies.
The core of activities
of iteration planning is carried out on a team-by-team basis:
Individual teams determine their actual capacity, or the amount
of work they can get done within the iteration.
Individual teams decompose as many features as seem to fit in the next iteration
into tasks.
Every task is estimated, with a typical task size of a half-day to two
days.
The "done" definition is taken into consideration - a feature is not done
until it has been fully tested and accepted
by the product owner.
The results of the
individual teams are inspected in a joined session to determine dependencies
(or the disappearance of them) that were not seen during the release planning
session.
Level 5 - Daily Plan
The stand-up meeting is
part of everyday life for agile teams. This daily meeting is not often seen as
a planning session, but it certainly is. The people look a day ahead, have
learned from the earlier days in the iteration, and tell each other what they
plan on doing. Issues are raised, possibly addressed, and the success of
delivering the desired features within the iteration can be determined after
the meeting.
How To: Have a Stand-up
Meeting
Like other planning
activities, daily plans need to be synchronized between teams. This takes place
in a coordinating stand-up meeting - a ‘Scrum of Scrums.' Representatives from each
team report the status, plans, and impediments to each other in an identical
format. The three questions answered are the same as in the individual stand-up
meetings:
How are all the teams progressing?
What are the cross-team impediments?
Who is taking the actions to remove them?
The principle of a
coordinating stand-up meeting can be repeated to address large numbers of teams
where representatives of ‘teams of teams' report on the progress of the ‘teams
of teams.' These meetings typically coordinate efforts of teams that have no
common ground. For example, all the IT delivery teams have a daily coordinating
stand-up, as do the training teams, finance teams, pre-production teams, and so
on. On a weekly schedule (or daily if it is late in the release cycle),
representatives of each team meet to report progress, plans and impediments.
Conclusion
In short, it is possible
to apply the ‘barely sufficient' principles of agile methods to multi-team,
long-term projects. Added levels of planning are not artificial or time
consuming, and they help focus the right group of people on the product with
the right level of detail, thus avoiding spending large amounts of time and
money before the actual delivery of features begins. Understanding the term
"acceptably inaccurate" is incredibly importance: When any member of the team
desires to hang on to details of work specification and planning, then agile
implementation is on its way back to waterfall methods.
About the author With more than 20 years
of software project management and IT expertise, Hubert has helped hundreds of
software team members successfully transition dozens of projects to agile and
lean practices. In doing so, he has also coached the executive management teams
who must deliver business value through their teams' agile adoption. Born in
the Netherlands,
Hubert is an Agile Coach for Rally Software, a Certified Scrum Trainer and a
frequent speaker at industry events.
[1] Moore & McKenna, "Crossing the Chasm," Capstone
Publishing, 1999.
Home 
