Release Planning: Envisioning the Overall Schedule

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• Defining the Pieces of a Release Plan
• Completing the Release Plan by Assigning Features to Iterations
• Communicating the Release Plan with a Kickoff Meeting
• Key Points
• Copyright

If you work with a smaller team doing smaller projects, it may be relatively easy to create a release plan: you define the iteration length and see how many iterations will fit into the window of time allotted for the project. But as projects grow in size, complexity increases, and so does the need for coordination. Our case study is emulating a medium-size project team working on a medium-size project. We’ll stay within the medium-size context as we discuss the pieces of a release that most teams need to consider when creating their release plan.

If we reflect for a moment, Acme Media has spent one week taking its medium-sized project through feasibility, chartering, and creation of feature cards. In this chapter, you’ll watch as Acme Media gathers additional information and outlines its release schedule.

Sometimes, confusion exists about the terms release and project. In the instance of your pilot project, release and project are synonymous. Although every iteration of the Auctionator will deliver releasable software, the initial goal of the project is to wait until all iterations are complete before releasing.

Acme Media still needs to gather some additional information before outlining a release plan. Let’s start the chapter by finding this information.

Defining the Pieces of a Release Plan

Once you have a prioritized, estimated backlog, you still need a few more pieces of information to create your release plan. You need to determine the length of iteration 0 (zero), the length of your development iterations, how much time will be needed between iterations, and the project deadline. Let’s look at how you obtain each item.

Iteration 0 Length

Iteration 0 represents the time needed to prepare the project for development iterations. This work can include completing contracts with third parties, preparing development environments, preparing development machines, setting up a project wiki, obtaining funding, and organizing support tools such as bug trackers.

You determine the time needed for iteration 0 based on how long it takes to get these items completed for your project. In Acme Media’s case, the Auctionator doesn’t require extensive time for preliminary setup work. The development environments are already in the correct state for development, and incremental funding isn’t needed for the project. Acme Media decides to complete four items before the development iterations:

• Create a new project within Acme’s bug-tracking tool

• Begin testing the API provided by the messaging vendor to make sure connections and firewalls work correctly

• Continue to envision and model the architecture

• Hold a project kickoff meeting

The project manager, Wendy Johnson, discusses the items with the team, and together they estimate that the preliminary work can be completed in one week. Acme records one week for iteration 0 in its release plan.

Development Iteration Length

If you’re working on your first Agile project, like Acme Media, you don’t know what a good iteration duration is for your project. You know that you want to build the critical pieces of the system as soon as you can, but how long will it take?

Fortunately, thousands of Agile projects have been completed across many industries, and you can learn from them. Extreme Programming (XP) environments frequently have iterations of 1 to 2 weeks in length. Scrum teams like to do a sprint/ iteration every 30 days. More than likely, a number between 1 and 4 weeks will work for your environment.

We suggest that you start with 2-week iterations and see how that timeframe works for you. It may be good to use this 2-week iteration length for several projects before making the call on whether it’s successful. If you find that your features are too large to complete in 2 weeks, you can examine your features to see if you’ve broken them

down to their true, essential requirements; alternatively, you can try a longer iteration length. Acme Media has followed this advice and created its release plan assuming 2week iterations.

How Long Do You Need Between Iterations?

Scrum has a structured process for completing a sprint/iteration and getting back to work quickly. When an iteration is completed, the product is demonstrated and (you hope) accepted. The team then goes through the following steps to initialize the next iteration:

1. Perform a sprint retrospective.

2. Return to the backlog, which may have changed while the team was in the sprint. If it has changed, the product owner is asked to prioritize the work.

3. Plan the next iteration based on estimates and the estimated iteration capacity.

4. Begin working on the next iteration.

Many Scrum teams complete this work in 1 or 2 days, which is somewhat amazing. If you’re just becoming Agile, it will be difficult to wrap up a sprint and start a new one in 2 days. A 1 to 2-day turnaround demonstrates a mature team with a well-oiled process. It will take time for your team to develop this rhythm.

As a starting point, we suggest that you space iterations approximately 1 week apart until your team matures around your Agile process. You won’t be well oiled right out of the gate, and a week between iterations will let you breathe a little as you’re adapting to your new methodology.

We also find that many projects need the additional time to wrap up an iteration. Here are the tasks we frequently see between iterations:

• Completion of acceptance testing

• Load testing of a completed iteration

• Demonstrations to the customer and stakeholders

• Usability testing

• Iteration retrospective

• Review of the backlog, and planning for the next iteration

As you can see, a lot of work may take place between iterations, and completing it in 2 days can be difficult.

Some Agile coaches would say that the work you list as “between iteration” work is part of the iteration. The argument is that acceptance testing, performance testing, and re-planning are iteration activities. We don’t have an issue with this perspective, but we’ve chosen to model our case-study iterations without these tasks. If you wanted to, you could include these tasks and say that Acme Media has 3-week iteration windows. Now that Acme Media has determined its iteration length, the company can proceed to outline an overall timeline for the project.

Note

Who Is Watching the Store While You’re in the Iteration?

In our early experience, most discussions of Agile suggested that the project team was dedicated to the project, and some other group took care of any issues encountered in the production environment. In recent years, we’ve seen a shift in that mentality; many people now factor in production support when determining team capacity for an iteration. Many companies have only one team for projects and production work.

In 2004, Greg worked with the internet team at the Seattle Times Company. The Seattle Times team factored production support into their capacity estimates, but they also decided to add a support buffer to their break between iterations. Although the team needed only 2 to 3 days to review one iteration and continue to the next, they added an additional 2 days to address production issues that could wait. The 5-day window allowed the team to plan for the next iteration while cleaning up any noncritical issues.

Determining the Overall Timeline

Most projects are constrained by time, and the overall schedule is built to support this constraint. Here are some typical causes for a time constraint:

• Your sales team sells a project to a customer.

• You need to put something in place to meet a regulatory timeline.

• You have an ongoing release schedule, and you must complete the work within the predefined window.

• You have only a limited amount of time to use employees on a project (employees may come from a shared pool).

• You have a fixed budget, and once that money is spent, so is your time.

• You need to beat your competitor to market.

To determine your timeline, you must review the total time available for your project. In most instances, your timeline starts with today and ends on the date requested by the customer or stakeholder. For our purposes, today is equal to the day you complete the story-point estimates for your features.

You can see the constraint model applied if we return to the Auctionator project. For the Auctionator, today is equal to April 20. Acme Media’s stakeholders have asked that the project be completed in 8 weeks, which means the Acme Media team has from April 20 to June 15 to deliver the project.

Once Wendy has the overall timeline, she takes the other information she’s collected (time for iteration 0, iteration length, and time needed between iterations) and begins outlining an iteration-by-iteration schedule in Microsoft Excel (see Figure 15.1).

Wendy uses Microsoft Excel because she’s comfortable with the tool and can post the schedule on the project wiki. But Wendy understands the importance of keeping the schedule in front of the team, and she uses an office plotter to print the schedule and post it prominently in the team area.

Figure 15.1 A release plan will begin to take shape after you’ve determined your overall project window, iteration length, and time spent to prepare between iterations. Most teams need extra time at the end of a project to prepare for deployment.

Now that Acme Media has an outline for the project timeline, the team can complete their project plan by plugging the features into the schedule.

Note

Just Two Iterations?

Acme Media has only two iterations in its pilot project, which is a minor change from the company’s previous development process. In theory, you want more iterations so you can demonstrate and react to new information sooner. But in the case of a pilot project, two iterations are fine. The team is just learning Agile techniques, and they can increase the number of iterations on subsequent projects.

Completing the Release Plan by Assigning Features to Iterations

After you’ve identified your release schedule, you can assign features to the iterations. This process isn’t difficult because you’ve already prioritized and estimated your features.

You assign features to iterations based on the velocity you’ve demonstrated in the past. For example, if you’ve historically averaged delivering 25 story points per iteration, you’ll use 25 story points for your capacity when scheduling new releases.

If you’re doing a pilot or first-time Agile project, you don’t have any history on which to base your capacity. In this instance, you proceed to detailed planning of your first iteration. In detailed planning, you’ll have the team break down each feature into tasks and perform estimates at the task/hours-needed level. After you complete detailed planning of the first iteration, you can see

how many story points are assigned to the first iteration and use that number as your capacity for subsequent iterations.

Completing a release plan is a little more complex than assigning features based on capacity. You also want to consider the following guidelines during the assignment process:

• Deliver usefulness to the customer in every iteration. In a perfect world, each iteration would be released and provide some level of value to the customer. Acme Media will do this for iteration 1 of the Auctionator. The company will deliver the minimal set of features needed for a working system.

• Consider dependencies between features. Features may be dependent on each other to provide value, so you shouldn’t split them across iterations. For example, the ability to record seller feedback is of no value unless the ability to view seller information is also completed.

• Put high-priority, high-risk features in early iterations. You want high-priority, high-risk features to go into early iterations so you have more time to work out the issues that correlate to the risk. Acme Media understands that features dependent on third parties are always high risk, and the team begins testing their vendor’s interface during iteration 0 to get a jump on potential risks.

Let’s rejoin Acme Media to see the guidelines in action.

Assigning features to iterations at Acme Media

When Acme Media completes detailed planning for iteration 1, the team finds that they’ve assigned 19 story points into the iteration. For now, 20 points will be used as the capacity number, so they plan iteration 2 to hold 20 story points.

Note

Projects without Time Constraints

The Auctionator is time-constrained to represent the most common projects we encounter when working with Agile teams. But on occasion, we see a project that is driven by feature richness, meaning the project goes on for as long as it takes to deliver all the features requested. In such an instance, you lay out a project plan with as many iterations as needed to complete the work.

Wendy, the project manager, loads up the iterations based on the work the team provided (see Figure 15.2).

Now that Acme Media has a release plan, the team is ready to hold a kickoff meeting and share the information with stakeholders, executives, and support groups they will depend on.

Figure 15.2 The completed release plan for the Auctionator project. The numbers in parentheses represent story-point estimates. Acme Media has estimated its story-point capacity at 20 points per iteration. After loading, iteration 1 holds 19 points, and iteration 2 contains 20 points.

Communicating the Release Plan with a Kickoff Meeting

Acme Media has involved the entire project team in creation of the release plan, so the team is up to speed on why the project is being pursued, the overall timeline, and the features assigned to each iteration. Acme still needs to bring other groups on board to make sure the project is supported and to create awareness about support that may be needed.

The first objective of the kickoff meeting is to bring stakeholders and sponsors up to speed. The project team shares the information gathered during the feasibility and

chartering exercises, including scope, benefits, key dependencies, constraints, risks, and the release schedule.

In a traditional environment, the presentation may be performed by a project manager or development manager. In an Agile environment, you should try to get as many team members to present as feel comfortable doing so. At Acme Media’s kickoff, four team members present: Wendy, the project manager, Jay, the customer, Gina, the tester, and Roy, the developer.

A second objective of the kickoff meeting, and perhaps the most important, is to bring support groups up to speed so they can see when their help may be needed. Some of the support areas typically discussed during a kickoff meeting are as follows:

• Operations. These teams will support your application once it’s deployed, and they need to know what type of maintenance will be required to keep the application working correctly.

• Security. In larger companies, your application may need to be reviewed to make sure it complies with corporate standards.

• Load testing. In larger companies, you may need to reserve load-testing equipment.

• Load balancing. You may have specialized groups that manage load-balancing environments, and you’ll need their support for your project.

• Hardware and storage. If you’re doing a project that requires new equipment, you may need help from hardware teams.

• Documentation. If your project will require supporting documentation, you may want to invite documentation teams to your kickoff.

• Marketing. If you need to do public announcements or advertising, you must bring this team up to speed with your release plan.

• Training. If your project will require training for employees or customers, you should invite this team to the kickoff.

Note

If you work with a small team, all of this work may be covered by the same team that does development. But if you work for a larger company, you probably already have experience dealing with support groups and can relate to the support categories we’ve outlined.

You can expect questions during the kickoff meeting, and there may even be discoveries that force you to adjust your release plan. Many teams create their release plan and rarely modify it during the project; but you should plan to modify your release plan frequently. Discoveries and adaptation will occur throughout your project. This is part of the value of having your release plan physically represented on a status wall. You can move pieces around quickly when things change, without needing to go into a tool such as Microsoft Project.

You know that dates will change as you make discoveries during your project. Use the project kickoff meeting to stress this point with stakeholders. Acme Media reminds stakeholders that June 15 is the current estimate, not a guaranteed hard date.

Note

Tools for Creating a Release Plan

You can document your release plan in a multitude of ways. You can sketch it on a whiteboard, use butcher paper and index cards and create it on a wall, or go electronic and use tools such as Microsoft Excel and Microsoft Project. You can also pursue tools that were made just for Agile development, such as those available from VersionOne and Rally Development.

In our experience, you should choose the tool that is easiest for you to maintain while still making it possible to keep your team and stakeholders up to speed on timing and status. This may include using additional tools such as burn down charts.

A good rule of thumb is the larger the project, the more need there is to create the plan electronically so that it can be distributed and viewed throughout the enterprise. If the project or your company is relatively small, you can have stakeholders visit the team room to review the release plan.

Mike Cohn makes a good suggestion, that you should not even propose a delivery date, but instead provide a delivery range so that expectations aren’t set for a specific date. For example, the Acme Media team will go into the kickoff meeting and say that they expect to deliver the project sometime between June 8 and June 22.

Key Points

The key points for this chapter are as follows:

• The main driver for your release schedule is the length of your development iterations. You must experiment to see what length works best for your work mix and team. A good length is usually somewhere between 2 and 4 weeks.

• You need time between iterations to demonstrate, adapt, and re-plan. Some teams can do this work within 2 days. Teams new to Agile should allow more time, taking as much as 5 days between iterations.

• Most projects are constrained by a target-completion date. You can create your release plan by working backward from this target date.

• Features are assigned to iterations based on priorities and estimated size. One person can do the assignments and review them with the team, or the team can assign the features together.

• In larger organizations, you need to communicate the release plan to stakeholders and support groups.

Previous article: Estimating with Story Points

Continue on to the next article: Iteration Planning: The Nitty Gritty Details

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.