In agile, loading a teamwith work is done through iteration planning. For very small projects, itlsquo;soften sufficient to plan only a single iteration at a time. But when iterationplanning is applied to projects that run for more than a few iterations orinvolve 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
gt;gt;Register Here

In plan-driven andwaterfall methodologies, this problem is overcome through a large upfrontdesign, aiming to predict accurately how much work is involved in each projectactivity. This leads to a large investment early in the project, when it is byno means certain that the designed functionality is actually desired by theproduct owner. Any agile approach to large-scale development has to avoid thereintroduction of the big design up front. One solution is to add planninglevels to incorporate a view {sidebar id=1} of lsquo;the whole.'
Agile planningactivities for large-scale development efforts should rely on five levels:

• Product Vision

• Product Roadmap

• Release Plan

• Iteration Plan

• Daily Commitment

The certainty ofundertaking activities addressed in each of the five levels increases as the planning horizon reduces from a year, to aquarter, and then to two weeks (see Figure 1). Therefore, the amount of detailaddressed, the number of people involved, and the frequency of planning anddesign activities can increase without running the risk of spending money onfeatures that may not be built or may be built differently.

{C}

Figure 1: Agile planningactivities for large-scale development efforts

Level 1 - Product Visioning

The broadest picturethat 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 likeafter the project finishes. She indicates what parts of the system need tochange (establishing priority) and what efforts can be used to achieve thisgoal (establishing estimates and commitments).
How To: Lead a ProductVisioning Exercise
The product visiondescribes a desired state that is six months or more in the future. Furtherplanning activities will detail the vision, and may even divert from the visionbecause the future will bring us a changed perspective on the market, theproduct, and the required efforts to make the vision reality.
There are several possiblestructures for a visioning exercise, two of which are to create an elevatorstatement[1]or a product box.[2] Theprinciple of both exercises is to create a statement that describes the futurein terms of desired product features, target customers, and key differentiatorsfrom previous or competitive products. Anyone who has gone through CertifiedScrumMaster training is likely familiar with the product visioning exercise.
Level 2 - Product Roadmap
The era of large-scaleprojects that deliver results in years is behind us. Customers demand morefrequent changes, and time-to-market is measured in weeks or months. The higherfrequency and smaller timeframes force a product owner into thinking in steps -into thinking of a road towards the final product. Just like a journey isplanned upfront and shared with fellow travelers, a product roadmap is createdand communicated to fellow delivery people.
The goals for doing soare 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, onthe 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 aProduct Roadmap

The creation of theroadmap is largely driven by the product owner in a single meeting or a seriesof meetings. This can be done, quite literally, through a graphicalrepresentation of the releases, or more formally in a written documentoutlining dates, contents, and objectives of the foreseen releases.
In anticipation of thenext planning stage, a list of desired features also needs to be built - thisis the product backlog. In its simplest form, such a backlog is a table orspreadsheet of brief product requirements, so the delivery team can provideestimates for delivery of each feature. Because the success of an agile projectdepends on the early delivery of the highest priority features, the list mustbe prioritized. And because the success of a project is measured in businessterms, 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 toproduce estimates that have an acceptable inaccuracy. Characteristics of aproduct 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, theproduct backlog alone can provide enough project overview. The size, durationand deliverables are easily recognized, and there is no need to synchronize orgroup deliverables or teams. All of this changes when applying agile conceptsto programs. The first moment to start grouping activities and allocating themto teams occurs during release planning.
A release is what thename 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 atthe system or program level, usually in product owner vocabulary. The releasetheme, release date, and prioritized features together form a release as definedby 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 nextrelease. Near-term releases have more detail in the feature descriptions and havesmaller individual features. A release can stretch over six to nine months,although two to four months is more common.
An iteration, on theother hand, is defined at the feature level. The delivery team and productowner have agreed on the number of iterations in a release. Features deliveredin an iteration are determined by the priority, and the number of featuresdelivered is set by the velocity of the team and the team estimates of thefeatures. Iteration lengths vary from one to six weeks, with two weeks as themost frequent duration.
How To: Conduct ReleasePlanning
A release planningsession typically takes place over a full day or sometimes two, if the programis very large (hundreds of team members). All team members participate in thesession, including product owner, full delivery team, and stakeholders. Releaseplanning should be highly collaborative and interactive. Tools used aretypically sticky notes, flipcharts, and whiteboards, and results will bemanaged 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 quot;Donequot;).

• 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 iterationwithin the release, a planning session takes place to add detail and increaseaccuracy. Before or during the session, detail is added to the features bydecomposing them into tasks. The actual capacity of the individual teams isknown with more certainty than during the release planning session. Thecombination of these increased accuracies helps the team commit to delivering anumber of features during the iteration with a high degree of certainty.

How To: Plan an Iteration
The structure of the iterationplanning session resembles release planning, with the prime distinction of theplanning horizon - only a single iteration. Although the teams work individuallyto produce their iteration plan, synchronization between teams provides an effectivemechanism to detect and resolve dependencies.
The core of activitiesof 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 quot;donequot; 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 theindividual teams are inspected in a joined session to determine dependencies(or the disappearance of them) that were not seen during the release planningsession.
Level 5 - Daily Plan
The stand-up meeting ispart of everyday life for agile teams. This daily meeting is not often seen asa planning session, but it certainly is. The people look a day ahead, havelearned from the earlier days in the iteration, and tell each other what theyplan on doing. Issues are raised, possibly addressed, and the success ofdelivering the desired features within the iteration can be determined afterthe meeting.
How To: Have a Stand-upMeeting
Like other planningactivities, daily plans need to be synchronized between teams. This takes placein a coordinating stand-up meeting - a lsquo;Scrum of Scrums.' Representatives from eachteam report the status, plans, and impediments to each other in an identicalformat. The three questions answered are the same as in the individual stand-upmeetings:

• How are all the teams progressing?

• What are the cross-team impediments?

• Who is taking the actions to remove them?

The principle of acoordinating stand-up meeting can be repeated to address large numbers of teamswhere representatives of lsquo;teams of teams' report on the progress of the lsquo;teamsof teams.' These meetings typically coordinate efforts of teams that have nocommon ground. For example, all the IT delivery teams have a daily coordinatingstand-up, as do the training teams, finance teams, pre-production teams, and soon. 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 possibleto apply the lsquo;barely sufficient' principles of agile methods to multi-team,long-term projects. Added levels of planning are not artificial or timeconsuming, and they help focus the right group of people on the product withthe right level of detail, thus avoiding spending large amounts of time andmoney before the actual delivery of features begins. Understanding the termquot;acceptably inaccuratequot; is incredibly importance: When any member of the teamdesires to hang on to details of work specification and planning, then agileimplementation is on its way back to waterfall methods.

About the authorWith more than 20 yearsof software project management and IT expertise, Hubert has helped hundreds ofsoftware team members successfully transition dozens of projects to agile andlean practices. In doing so, he has also coached the executive management teamswho must deliver business value through their teams' agile adoption. Born inthe Netherlands,Hubert is an Agile Coach for Rally Software, a Certified Scrum Trainer and afrequent speaker at industry events.

[1] Moore amp; McKenna, quot;Crossing the Chasm,quot; CapstonePublishing, 1999.

[2] Highsmith, quot;Agile Project Management,quot; Addison-Wesley,2004.

[3] Tabaka, quot;Collaboration Explained,quot; Addison Wesley,2006.