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

>> Register Here
 

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  {sidebar id=1} 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

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.

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.

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.

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.

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.

[1] Moore & McKenna, "Crossing the Chasm," Capstone Publishing, 1999.

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

[3] Tabaka, "Collaboration Explained," Addison Wesley, 2006.

Trackback(0)

TrackBack URI for this entry

Comments (1)

...
written by wrein, July 11, 2009

this is very useful thanks a lot..

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview