Iterations

I l @ ve RuBoard

Our general advice is to keep iterations small. Think of building a Web site as rock climbing, with the length of an iteration similar to the distance between each safety stop you hammer into the rock face. There is overhead attached to stopping and hammering in a piton, just as there is in each iteration strategy and planning session, and this overhead tempts people to extend the period between each safety stop and press on. The best way to determine the optimum stopping point is to decide how far you are willing to fall. There is a distance that is so short that not enough has changed to bother replanning. There is also a distance that is so long that a fall can be fatal.

In XP we want to find a sweet spot. From the customer to your own team, short iterations keep you out of trouble by finding problems early and giving everyone an opportunity to continuously reevaluate priorities and requirements.

Iterations are safety stops, where teams can reestimate; they also give teams a sense of accomplishment.

Keep to Two-Week Iterations and Independent Stories

We recommend that Web projects follow a two-week iteration schedule. This is good because it allows you to work on a number of stories across the Web site without having to include one that depends on another. When one story depends on another story, your team cannot start working on the dependent story until the first one is finished. At the very least you will find that the unforeseen risks of the first story are present in related stories. When we first started using XP, we planned a number of stories in an iteration that depended on each other. By doing so we reintroduced the risk of our old waterfall process. When the first story in the chain took twice the time we estimated, the resulting delays cascaded into every other story, and at the end of the iteration we had very little to show for our time. However, when we planned iterations with stories that were completely unrelated, we could run into serious trouble on one story and still deliver all the others.

Why not one week? There is no reason that you cannot do one-week iterations, but we steer away from them because they provide too little room to move. Stories that turn out to be longer than estimated still get done in a two-week iteration, whereas in a one-week iteration they have to be dropped. The graphic design process calls for a number of stories that consistently take two weeks. Moreover, few customers have the time to do iteration meetings every week. Finally there are the intangibles, including the bigger sense of accomplishment to be had from the deliverables of a two-week iteration than from a single week. Your experience may vary but we have found that two weeks is a long enough iteration to make good progress without adding unnecessary risk.

Plan Iteration Strategy

For us every iteration starts with two key meetings: first the iteration strategy meeting followed immediately by the iteration planning meeting. To simplify this process with customers, we book these meetings at the beginning of the project, for the entire project. Because we know that every iteration will be exactly two weeks long, we know exactly when these meetings will be held. This reduces the amount of scheduling problems in the future.

The Strategy Meeting

The focus of the strategy meeting is on the overall goal and direction of the project. Customer, strategist, project manager, design lead, and technical lead attend ”all of the key people who will help the customer develop stories and provide a goal for the coming iteration.

The first task of this meeting is to write new stories or change existing ones. This is done not only by the customer but also by team members . At the beginning of the project, more stories will be developed by the team than by the customer, but as the project goes on the customer will write more and more. For each story the team will provide a ballpark estimate, whose purpose is to provide the customer with a rough idea of the amount of work involved.

The next step is defining the metrics for success. Try asking the following questions:

• Will this story generate traffic?

• Will this story generate new revenue or increase existing revenue?

• Will this story help change patterns of behavior?

• Will this story help reduce costs?

By discussing the amount of work a feature involves and its benefits or drawbacks, the customer can assign a priority to each story.

The Planning Meeting

The goal of the planning meeting is to involve the team in the process and more clearly define what will be done in the coming iteration. Everyone involved in the project attends. The meeting begins with the review of stories that the customer wishes to complete. Every person on the team can ask whatever questions they need answered to gain a full understanding of what the customer is requesting.

For each story the team assesses all of the tasks necessary to complete the story along with the potential risks and maps out possible solutions to these risks. As content delivery is the most frequent cause of delay in Web site development, we define the content requirements at this point to help the customer understand the ramifications of delivering late.

When the development team fully understands what is expected from each story, they provide their estimates for how long stories will take to complete. Allowing the team to volunteer for stories is critical.

At the end of the iteration, with all of the information reviewed and the estimates tallied, it is time for the customer to make decisions, this time, on what they want to do in the following iteration.

To get approval on the final plan, the project manager produces a simple document listing the stories the customer has chosen for the team to work on along with the estimated time each will take to complete and the total number of hours the iteration will require.

Plan for Width Before Depth

Web sites can be wide and deep. Wide refers to the number of unrelated functions to be found on a site, and deep refers to the complexity of those functions. When possible take advantage of the width to vary the stories in an iteration. This is better for the customer because when the team focuses on one function and runs deep on it in one or two iterations, the customer loses the opportunity to evolve the application. The customer will give better input to the team if an application comprising five stories is delivered one story per iteration over five iterations rather than five in one. In general we recommend that, say, five pieces of functionality in a Web project be built a story at a time over a number of iterations. Doing this allows the team to explore risks early in the process by doing the riskiest stories for all functions; it also lets the customer re-evaluate requirements as he sees the project unfold.

Make Customer Input Easy and Controllable

Short iterations are also a good customer management strategy. Imagine walking into your first iteration planning meeting and asking a new customer to decide on a month's worth of work. You will invoke paralysis. Further, you are asking for more trust than may exist so early on. Many of your customers will not be used to the iterative process and will be feeling uneasy about starting the project without the reams of design documents they are accustomed to. Take it slow and prove the merits of XP in short easy-to-digest chunks with ample time for deliberation and feedback.

Ask any Web developer what railroads every project and she will tell you it is waiting for content from the customer. On most projects the customer is responsible for delivering either the copy or approval of it. He also needs to get you database schemas of legacy applications, corporate logos, contact information, and other Web site content. Before XP we would generate a list of everything we needed and wait for the customer to deliver. And wait, and wait.

Using XML you can press on with a project without much content, but you still can't launch without it. That's why short iterations are good ”they let the customer deliver small parts of the content every two weeks. With small homework assignments, the odds of keeping a continuous pace are much higher. You also reduce risk by determining quickly if the customer is going to be able to do his part. Once he misses a small delivery, you quickly learn that you have a problem and can work out a new strategy to get the content.

In many cases you are getting content from more than one customer on a project. When you find out who delivers and who doesn't, you can reorganize delivery to shift more critical responsibility to proven performers. If the customer is hopeless, you can send a team member to his office to gather the content or hire a writer to do the bulk of the job.

Keep Track of Tasks

Once the customer has approved the iteration plan, the team starts work on the stories. Each story is posted at the top of the project board with associated tasks listed below. Every morning the team meets to walk through each task. At the first stand-up meeting of the iteration, team members volunteer for tasks by estimating how long they think they will take to complete. Every day they report on their progress, updating their estimates and discussing any problems. As tasks are completed they are crossed off the list. This boosts team morale and makes both the project manager and the customer happy.

Keep the Customer Involved in Delivery

After two weeks an iteration is over, which means that it is time to meet to present the deliverables. Since a story isn't completed until it has been proven, this includes walking the customer through any stories that she has not approved; the meeting cannot end without customer approval. Any story not approved by the customer is considered incomplete and is postponed to a later iteration. As early as possible before the end of the iteration, the project manager should advise the customer if a story will not be completed by that time.

I l @ ve RuBoard