in 99 words
Iterations are timeboxed to one week and follow a strict schedule:
- Plan iteration
- Commit to delivering stories
- Develop stories
- Prepare release
- Demonstrate release
- Hold retrospective
To plan, measure the velocity of the previous iteration (total the estimates of "done done" stories). Select stories from the release plan that match the velocity. It shouldn't take long.
Assuming programmers are your constraint, they brainstorm and estimate engineering tasks. Ask the on-site customer about detailed requirements when necessary. Compare the task estimates to last iteration's to confirm the plan's feasability.
Post the stories and tasks prominently and mark them when complete.
New Information
Kanban Systems
Full Text
The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.
Iteration Planning
- Audience
- Whole Team
We stop at predetermined, unchangeable time intervals and compare reality to plan.
- Allies
- Stories
- Release Planning
Iterations are the heartbeat of an XP project. When an iteration starts, stories flow in to the team as they select the most valuable stories from the release plan. Over the course of the iteration, the team breathes those stories to life. By the end of the iteration, they've pumped out working, tested software for each story and are ready to begin the cycle again.
Iterations are an important safety mechanism. Every week, the team stops, looks at what it's accomplished, and shares those accomplishments with stakeholders. By doing so, the team coordinates its activities and communicates its progress to the rest of the organization. Most importantly, iterations counter a common risk in software projects: the tendency for work to take longer than expected.
The Iteration Timebox
Programming schedules die in inches. At first you're on schedule: "I'll be done once I finish this test." Then you're limping. "I'll be done as soon as I fix this bug." Then gasping. "I'll be done as soon as I research this API flaw... no, really." Before you know it, two days have gone by and your task has taken twice as long as you estimated.
Death by inches sneaks up on a team. Each delay is only a few hours, so it doesn't feel like a delay, but they multiply across the thousands of tasks in a project. The cumulative effects are devastating.
Iterations allow you to avoid this surprise. Iterations are exactly one week long and have a strictly defined completion time. This is a timebox: work ends at a particular time regardless of how much you've finished. Although the iteration timebox doesn't prevent problems, it reveals them, which gives you the opportunity to correct the situation.
- Allies
- Iteration Demo
- Slack
In XP, the iteration demo marks the end of the iteration. Schedule the demo at the same time every week. Most teams schedule the demo first thing in the morning, which gives them a bit of extra slack the evening before for dealing with minor problems.
The Iteration Schedule
Iterations follow a consistent, unchanging schedule:
- Allies
- Iteration Demo
- Retrospectives
- Ten-Minute Build
Demonstrate previous iteration (up to half an hour)
Hold retrospective on previous iteration (one hour)
Plan iteration (half an hour to four hours)
Commit to delivering stories (five minutes)
Develop stories (remainder of iteration)
Prepare release (less than ten minutes)
Choose an iteration start time that works for your team and stick with it.
Many teams start their iterations on Monday morning and end Friday evening, but I prefer iterations that start on Wednesday morning. This allows people to leave early on Friday or take Monday off without missing important events. It also allows the team to conduct releases before the weekend.
How to Plan an Iteration
- Ally
- "Done Done"
After the iteration demo and retrospective are complete, iteration planning begins. Start by measuring the velocity of the previous iteration. Take all of the stories that are "done done" and add up their original estimates. This number is the amount of story points you can reasonably expect to complete in the upcoming iteration.
Be sure to use estimated time, not actual time, when calculating velocity. This allows the velocity to account for interruptions and other overhead.
- Ally
- Release Planning
With your velocity in hand, you can select the stories to work on this iteration. Ask your customers to select the most important stories from the release plan. Select stories that exactly add up to the team's velocity. You may need to split stories (see Stories later in this chapter) or include one or two less important stories to make the estimates add up perfectly.
Avoid using the iteration planning meeting for extensive release planning. Do the bulk of your release planning during the previous iteration.
Because the iteration planning meeting takes stories from the front of the release plan, you should have already estimated and prioritized those stories. As a result, selecting stories for the iteration plan should only take a few minutes, with perhaps ten or 15 minutes more to explain:
Product Manager: Okay, here we are again. What is it this time? Iteration 23? [Writes "Iteration 23" at top of the blank iteration planning whiteboard.] What was our velocity in the previous iteration?
Programmer: [Counts up stories.] Fourteen, same as usual.
Product Manager: [Writes "Velocity: 14" on the whiteboard.] Okay, let's roll the release planning board in here. [Helps drag the planning board over, then points at it.] The other customers and I had some tough decisions to make after our recent release. Our users love what we've been doing, which is good, and they're making all kinds of suggestions, which is also good, but some of their ideas could easily derail us, which is not so good. Anyway, you don't need to worry about that. Bottom line is that we're sticking with the same plan as before, at least for this next iteration. So, let's see, 14 points... [starts picking stories off of the release planning board] three... five... six, seven... ten... twelve... fourteen. [He puts them on the table.] All right, everybody, that's our iteration. Good luck—I have to go talk with our division VP. Mary's going to stick around to answer any questions you have about these stories. I'll be back this afternoon if you need anything.
Mary: Good luck, Brian. [The product manager leaves.] We've talked about these stories before, so I'll just refresh your memory...
After you have chosen the stories for the iteration, everybody but the programmers can leave the meeting, although anybody is welcome to stay if she likes. At least one customer should stick around to answer programmer questions and to keep an ear out for misunderstandings.
The team's constraint determines how much the team can do in each iteration (see XP Concepts in Chapter 3 for more about the Theory of Constraints). This book assumes programmers are the constraint, so the iteration plan is based entirely on programmer tasks and estimates. Other team members may conduct their own iteration planning sessions if they wish, but it isn't required.
At this point, the real work of iteration planning begins. Start by breaking the stories down into engineering tasks.
Engineering tasks are concrete tasks for the programmers to complete. Unlike stories, engineering tasks don't need to be customer-centric. Instead, they're programmer-centric. Typical engineering tasks include:
Brainstorm the tasks that you need in order to finish all the iteration's stories. Some tasks will be specific to a single story; others will be useful for multiple stories. Focus only on tasks that are necessary for completing the iteration's stories. Don't worry about all-hands meetings, vacations, or other interruptions.
Some non-programming stories, such as a story to estimate a stack of other stories, can't be broken into tasks. Re-estimate the story in terms of ideal hours (see Estimating later in this chapter) and leave it at that.
Brainstorming tasks is a design activity. If everybody has the same ideas about how to develop the software, it should go fairly quickly. If not, it's a great opportunity for discussion before coding begins. Although brainstorming engineering tasks is a design activity, you don't need to go into too much detail. Each engineering task should take a pair one to three hours to complete. (This translates into about two to six hours of estimated effort.) Let pairs figure out the details of each task when they get to them.
As each team member has an idea for a task, he should write it down on a card, read it out loud, and put it on the table. Everybody can work at once. You'll be able to discard duplicate or inappropriate tasks later.
As you work, take advantage of your on-site customer's presence to ask about the detailed requirements for each story. What do the customers expect when the story is done?
Amy, John, Kim, Fred, Belinda, and Joe continue planning. Mary, one of the on-site customers, sits off to the side, working on some email.
"Okay, here we are again," deadpans John, mimicking their product manager.
Amy snickers. "These stories look pretty straightforward to me. Obviously, we need to implement new domain logic for each story. This warehouse stocking story looks like it will affect the warehouse and SKU classes." She takes an index card and writes, "Update warehouse and SKU classes for warehouse stocking."
"Speaking of products, now that we're going to be storing the weight of each SKU, we need to update the SKU class for that, too," says Belinda. She takes another card and writes, "Update SKU class to include weight." She pauses to consider. "Maybe that's too small to be a task."
Joe speaks up. "That weight story is mostly a UI change at this point. We'll need to update the SKU configuration screen and the administration screen. We can put weight into the SKU class at the same time." He starts writing another task card.
"Wait a second, Joe." Mary, the on-site customer, looks up from her email. "Did you say that the weight issue was only a UI change?"
"That's right," says Joe.
"That's not entirely true," says Mary. "Although we mostly need to add the ability to enter weight into the system for later use, we do want it to show up on our inventory report."
"Oh, good to know," says Joe. He writes, "Update inventory report with SKU weight" on a task card.
Kim and Fred have been talking off to the side. Now they speak up. "We've made some cards for the database changes we'll need this iteration," Kim says. "Also, I think we need to update our build script to do a better job of updating schemas, so I wrote a task card for that, too."
"Sounds good," says John. "Now, I think these other stories also need domain logic changes...."
After you've finished brainstorming tasks, spread them out on the table and look at the whole picture. Are these tasks enough to finish all of the stories? Are there any duplicates or overlaps? Is anybody uncertain about how the plan works with the way the software is currently designed? Discuss and fix any problems.
Finish brainstorming before you start estimating.
Next, estimate the tasks. As with brainstorming, this can occur in parallel, with individual programmers picking up cards, writing estimates, and putting them back. Call out the estimates as you finish them. If you hear somebody call out an estimate that you disagree with, stop to discuss it and come to consensus.
Estimate the tasks in ideal hours. How long would the task take if you had perfect focus on the task, suffered no interruptions, and could have the help of anybody on the team? Estimate in person-hours as well: a task that takes a pair two hours is a four-hour estimate. If any of the tasks are bigger than six hours of effort, split them into smaller tasks. Combine small tasks that are less than an hour or two.
Finally, stop and take a look at the plan again. Does anybody disagree with any of the estimates? Does everything still fit together?
- Ally
- Slack
As a final check, add up the estimates and compare them to the total task estimates from your previous iteration. Using this plan, can you commit to delivering all the stories? Is there enough slack in the plan for dealing with unexpected problems?
Comparing the total of your task estimates to last week's total will help you get a feel for whether the iteration is achievable. The two numbers don't need to match exactly.
Don't bother comparing your estimate to the actual number of hours you'll be working. There are too many variables outside of your control, such as estimate accuracy, interruptions, and nonproject meetings, for there to be a useful corollation.
- Ally
- Stories
You may discover that you aren't comfortable committing to the plan you have. If so, see if there are any tasks you can remove or simplify. Discuss the situation with your on-site customers. Can you replace a difficult part of a story with something easier but equally valuable? If not, split or remove a story.
Similarly, if you feel that you can commit to doing more, add a story to the plan.
Continue to adjust the plan until the team is ready to commit to delivering its stories. With experience, you should be able to make plans that don't need adjustment.
The Commitment Ceremony
Commitment is a bold statement. It means that you're making a promise to your team and to stakeholders to deliver all of the stories in the iteration plan. It means that you think the plan is achievable and that you take responsibility, as part of the team, for delivering the stories.
Hold a little ceremony at the end of the iteration planning meeting. Gather the whole team together—customers, testers, and programmers—and ask everyone to look at the stories. Remind everybody that the team is about to commit to delivering these stories at the end of the iteration. Ask each person, in turn, if he can commit to doing so. Wait for a verbal "yes".
Openly discuss problems without pressuring anybody to commit.
It's okay to say "no". If anybody seems uncomfortable saying "yes" out loud, remind them that "no" is a perfectly fine answer. If somebody does say no, discuss the reason as a team and adjust the plan accordingly.
- Ally
- Trust
Commitment is important because it helps the team consistently deliver iterations as promised, which is the best way to build trust in the team's ability. Commitment gives people an opportunity to raise concerns before it's too late. As a pleasant side effect, it helps the team feel motivated to work together to solve problems during the iteration.
After the Planning Session
- Ally
- Pair Programming
After you finish planning the iteration, work begins. Decide how you'll deliver on your commitment. In practice, this usually means that programmers volunteer to work on a task and ask for someone to pair with them. As pairs finish their tasks, they break apart. Individuals pick up new tasks from the board and form new pairs.
Other team members each have their duties as well. XP assumes that programmers are the constraint in the system, so other team members rarely have a task planning board like the programmers do. Instead, the customers and testers keep an eye on the programmers' progress and organize their work so it's ready when the programmers need it. This maximizes the productivity of the whole team.
Every team member is responsible for the successful delivery of the iteration's stories.
As work continues, revise the iteration plan to reflect the changing situation. (Keep track of your original task and story estimates, though, so you can use them when you plan the next iteration.) Remember that your commitment is to deliver stories, not tasks, and ask whether your current plan will succeed in that goal.
- Ally
- Ten-Minute Build
At the end of the iteration, release your completed software to stakeholders. With a good ten-minute build, this shouldn't require any more than a button press and a few minutes' wait. The following morning, start a new iteration by demonstrating what you completed the night before.
Dealing with Long Planning Sessions
Iteration planning should take anywhere from half an hour to four hours. Most of that time should be for discussion of engineering tasks. For established XP teams, assuming they start their iteration demo first thing in the morning, planning typically ends by lunchtime.
New teams often have difficulty finishing planning so quickly. This is normal during the first several iterations. It will take a little while for you to learn your problem space, typical approaches to design problems, and how best to work together.
If iteration planning still takes a long time after the first month or so, look for ways to speed it up. One common problem is spending too much time doing release planning during the iteration planning meeting. Most release planning should happen during the previous iteration, primarily among customers, while the programmers work on stories. Picking stories for the iteration plan should be a simple matter of taking stories from the front of the release plan. It should only take a few minutes because you won't estimate or discuss priorities.
The team may have a few new stories as a result of stakeholder comments during the iteration demo. In general, though, the customers should have already prioritized most of the stories.
Long planning sessions also result from spending a lot of time trying to break the stories down into engineering tasks. This may be a result of doing too much design work. Although iteration planning is a design activity, it's a very high level one. Most of the real design work will happen during the iteration as pairs work on specific tasks. If you spend much time discussing possible design details, ask yourself whether you really need to solve these problems in order to come up with good engineering tasks.
- Allies
- Collective Code Ownership
- Pair Programming
If you find that team members don't understand the existing design, or if you have long discussions about how it works, you may lack shared design understanding. Remedy this problem with collective code ownership and more pair programming.
- Allies
- Simple Design
- Test-Driven Development
If you find yourselves speculating about possible design choices, your problem may be a result of trying to make your design too general. Remember to keep the design simple. Focus on the requirements that you have today. Trust pairs doing test-driven development to make good decisions on their own.
- Ally
- Sit Together
Design speculation can also occur when you don't understand the requirements well. Take advantage of the on-site customer in your meeting. Ask him to explain the details of each story and why the system needs to behave in a particular way.
Tracking the Iteration
- Ally
- Informative Workspace
Like your release plan, your iteration plan should be a prominent part of your informative workspace. Put your stories and tasks on a magnetic whiteboard, as shown in Figure. When you start work on a task, take it off of the whiteboard and clip it to your workstation. (Mark your initials on the whiteboard so people know where the task went.) As you finish each task, put it back on the board and circle it with a green marker.
Figure. Iteration Planning Board
One of the difficulties in iteration planning is identifying that things are going wrong in time to fix them. I take a brief look at our progress every day. Is there a task that's been in progress for more than a day? It might be a problem. If it's halfway through the iteration, are about half of the cards marked green? If not, we might not finish everything on time.
After the iteration ends, take your cards down from the board, add a card on top with some vital statistics (iteration number, dates, whatever else you think is relevant), clip them together, and file them in a drawer. Alternatively, you can just throw them away. You're unlikely to come back to the cards, but most teams prefer archiving them just in case.
When Things Go Wrong
Does making a big deal out of commitment mean that you always deliver everything as promised? No, of course not. Commitment is about working around problems and doing what's necessary to deliver the iteration's stories—but sometimes a problem comes up that you can't work around.
- Ally
- Slack
When you discover a problem that threatens your iteration commitment, first see if there's any way you can change your plan so that you still meet your commitments. Would using some of your iteration slack help? Is there an engineering task that you can simplify or postpone? Discuss your options as a team and revise your plan.
Sometimes, the problem will be to big to absorb. In this case, you'll usually need to reduce the scope of the iteration. Typically, this involves splitting or removing a story. As a team, discuss your options and make the appropriate choice.
Always stay in control of your iteration, even if you have to change your plan to do so. Any iteration that delivers all of the stories in the current plan—even you changed the plan—is a success.
Under no circumstances, however, should you change the iteration deadline.
After changing the plan, the customers should re-establish trust with stakeholders by explaining what happened, why, and what the team is doing to prevent this sort of problem in the future.
Despite your best efforts, you may have a bad week and end up with nothing at all to demonstrate to your stakeholders. Some teams declare a lost iteration when this happens. They roll back their code and use their previous velocity as if the lost iteration never happened. Every team makes mistakes, so this is a fine approach if it happens rarely (less than once per quarter). If it happens more often, something is wrong. Ask your mentor for help.
Partially Done Work
- Ally
- "Done Done"
At the end of the iteration, every story should be "done done". Partially-completed stories should be rare: they reflect a planning problem. That said, they will happen occasionally, particularly when you're new to XP.
Some teams feel that the best way to handle partially-completed stories is to delete all of the code for uncompleted stories and deliver only what's completely done. This sounds harsh, but it's a good idea. "With true timeboxing, the software is either accepted or thrown away at the timebox deadline. That makes it clear that the quality level must be acceptable at all times. The success of timeboxing depends on being able to meet tight schedules by limiting the product's scope, not its quality." [McConnell, p.581]
You may delete code, but you won't delete what you've learned.
If you follow this practice, you probably won't throw away much code—the iteration is only a week long. Starting fresh may require you to rewrite code, but you'll retain everything you learned when you wrote it the first time. The second attempt will often produce better code and may even finish more quickly.
- Ally
- Version Control
If you think this is extreme, as long as you know you will definitely work on that story during the next iteration, it's okay to keep the code. However, if you will not immediately continue to work on that story, it's best to delete the code. Get it out of your way. It's technical debt and baggage. If you ever need it, you can always get it out of version control.
Emergency Requests
It's inevitable. You're on the third day of the iteration, everything is going well, and a customer comes up to you and says, "Pat, we really need to get this story in." What do you do?
As a programmer, it's very tempting to tell your customer to take a hike—right over the edge of a cliff. Changing direction in the middle of an iteration, after all, means an interruption in concentration, delays, and lost work.
On the other hand, responsiveness to business needs is a core agile value, so suppress that homicidal urge, smile, and provide your customer with options.
You can change the iteration schedule under the condition that you take out as much work as you add. In other words, if you're adding a two-point story to the plan, a two-point story needs to come out of the plan.
In addition, you may only replace stories that you haven't started yet. A two-point story that's half-done isn't a two-point story any more—but it's not a one-point story either. It's too difficult to tell how much work you have left on a story until it's "done done", and replacing it will lead to technical debt in the form of half-finished code.
Before making any changes, however, remember that your next planning meeting is less than a week away. Rather than inserting chaos into the team's work, ask yourself how much of an emergency you're really facing. Maybe it can wait until the next planning meeting. After all, it's only a day or three away.
The Batman
Dealing with an emergency request every now and then is fine—it's a great way for the team to be responsive. On the other hand, an emergency in every iteration means that something is wrong.
After the second or third iteration in a row with an emergency request, take a look at what's happening. Perhaps your on-site customers need to be more disciplined about release planning. Perhaps stakeholders need stronger reminders that requests can wait until the next iteration. Often the requests will die down as your organization adapts to the iteration heartbeat.
In some cases, however, the team has a legitimate need to provide ongoing support for ad hoc requests. If this is true for your team, sacrifice a programmer to be the batman.
Some teams have a dedicated phone for emergency support requests; this is, of course, the bat-phone.
"Batman" is a military term as well as a comic book character: it refers to a soldier assigned to deal with chores so that officers can focus on officering. On an XP team, the batman deals with organizational emergencies and support requests so the other programmers can focus on programmering. The batman has no other duties: he doesn't work on stories or the iteration plan.
Rotate a new programmer into the batman role every iteration to prevent burn-out. If the load is particularly high, you may need two or more batmen per iteration.
Depending on your situation, you may be better off using daily iterations rather than a batman. A daily iteration allows you to postpone all emergencies until the next morning, which enables the team to focus better (see the "Daily Iterations" sidebar). It's appropriate for teams that primarily deal with small ad-hoc issues, such as bug-fixes and minor enhancements, and don't have a long-term release plan.
- Ally
- The Planning Game
Questions
How should we schedule time for fixing bugs?
- Ally
- No Bugs
You should fix bugs as soon as you find them, preferably as you work on each task. This time is part of the overhead of your iteration. Don't batch them up for fixing later, even if "later" is as soon as the end of the iteration.
- Ally
- Slack
Some bugs will be too big to absorb into your iteration slack. Create story cards for these and schedule them as soon as possible—or decide that they aren't worth fixing at all.
If we don't estimate stories during iteration planning, when do we estimate stories?
Estimate new stories as they appear throughout the iteration. If this is too much of an interruption, batch up the stories and estimate them at a particular time every day.
If you have a lot of stories to estimate, as often happens near the beginning of a project, schedule time for estimation with a story.
All the available tasks depend on tasks that other pairs are working on right now. What should I work on?
This happens less frequently than you might think; breaking stories into engineering tasks helps modularize the design. However, it does happen.
It's okay to have two pairs working on the same class. In this case, discuss the issue and come to agreement about the names of the class and the public methods that both pairs will be using. Then pick one pair to write the class. The other pair creates the exact same class but, instead of writing real code, stubs in some hardcoded return values.
When you integrate, replace the fake class with the real one and make sure the tests still pass.
What should the batman do when there are no outstanding support requests?
Whatever she likes, as long as she can easily put it aside when a support request comes in. Don't try to squeeze every last drop of efficiency out of the batman; doing so will likely slow the team down and make the batman's job even more tedious.
Results
When you use iterations well, your team has a consistent, predictable velocity. Stakeholders know what to expect from the team and trust that it will deliver on its commitments. The team discovers mistakes quickly and deals with them while still meeting its commitments. Rarely, the team meets its commitments by replanning, changing its commitments, and communicating these changes to stakeholders.
Contraindications
- Allies
- Stories
- Simple Design
- Incremental Design And Architecture
XP's iterations assume the use of customer-centric stories. To successfully deliver software in such a short timescale, the team must use simultaneous phases as well as simple design and incremental design and architecture. If you don't use these practices, XP-style iterations probably won't work for you.
- Ally
- Slack
In order to achieve a consistent velocity and deliver on commitments, your iteration must include slack. Never artificially inflate your velocity. Similarly, don't use commitment as a club. Never force team members to commit to a plan they don't agree with.
- Ally
- Energized Work
Energized work is also important. Without it, the team will have trouble maintaining equilibrium and a stable velocity.
- Ally
- Release Planning
Finally, there's little value to a strict iteration schedule unless you pay close attention to the feedback cycles of velocity, planning, and frequent releases. A disciplined iteration schedule may improve predictability and estimation, but you must notice and react to changes in order to take advantage of it.
Alternatives
Some methods use longer iterations that release to real customers, not just to internal stakeholders, at the end of each iteration. Other methods use independent phases instead of simultaneous phases and iterations. Either of these approaches can work, but most of XP's practices assume the presence of short iterations. If you don't use XP-style iterations, talk with your mentor about whether XP will work in your situation.
Some established XP teams don't use engineering tasks at all. Instead, they use very small stories that can each be finished in less than a day. This approach works best for established products. Other teams use engineering tasks but don't estimate them. Either approach can work well, but they're advanced techniques. I recommend explicitly creating and estimating engineering tasks to start.
Iteration Length
Throughout this book, I've assumed that your team uses one-week iterations. However, iterations may be of any length. Many teams prefer two-week iterations.
I've found that shorter iteration lengths are better for teams new to XP. Teams seem to mature in their understanding of XP based on how many iterations they've undertaken rather than how many weeks they've experienced. As a result, shorter iterations means more rapid improvement for a team new to XP.
Short iterations allow the team to practice core XP skills more frequently. A short iteration leads to more planning, more internal releases, more iteration demos, and more retrospectives. They reduce the team's ability to use overtime to cover up scheduling flaws, which helps the team learn to estimate and plan well.
One-week iterations also make decisions easier by reducing schedule risk. If a discussion is taking too long, you can say, "This may not be perfect, but we'll review it again next week." This makes planning and retrospectives easier.
- Allies
- Energized Work
- Refactoring
On the other hand, one-week iterations put more pressure on the team. This makes energized work more difficult and can limit refactoring. Velocity is less stable in one-week iterations, because even one holiday represents a big loss of time for the iteration.
I prefer one-week iterations for new teams. For established teams that are comfortable with all of the XP practices, I prefer two-week iterations. Two-week iterations are a little less stressful and lead to a more stable velocity.
Three and four-week iterations seem too long to me. They don't provide enough feedback to the team or the larger organization. However, if you think that a longer iteration would be useful for your team, please try it. Be careful: longer iterations are more sensitive to mistakes, because it takes longer to expose and to recover from those mistakes.
Shorten your iteration length if you're having trouble with XP.
- Ally
- Energized Work
Don't use longer iterations if you feel that you need more time to get your work done. Longer iterations won't change the amount of time you have; they only change how often you check your progress. If you have difficulty getting your work done, shorten your iteration length (to a minimum of one week) and look at what you're doing to support energized work. Be sure to reduce your workload in each iteration proportionally. Shortening your iteration length will reduce the amount of work you have to do each iteration and will help you identify problems in your process.
Some teams base their iterations on a number of business days rather than a calendar. For example, rather than having a seven calendar-day iteration, the team's iterations are five business days long. This is helpful for one-week iterations because it reduces the impact of holidays on the team's velocity. However, I don't recommend business-day iterations because they're harder to schedule with stakeholders. The regular heartbeat of the XP team is an excellent way to generate trust, and business-day iterations don't have the same impact. It's nice to know that Wednesday is always the start of a new iteration.
Further Reading
Agile Estimating and Planning [Cohn] and Planning Extreme Programming [Beck & Fowler] each provide alternative ways of approaching iteration planning.
Comments
Your project schedule says that you will get 2 more team members this week and 3 more next month. How do you integrate them into the team? How do you bring them on board? How do you avoid slowdowns? In a word you can’t avoid the slowdown – adding new people to the project will slow the existing team down.
A recent challenge has made me realize that some things I thought were implicit need to be made explicit.
). I found the quote Steve mentioned on Wikipedia:
), participants said they got to see some very different ways of solving a problem from what they knew, so they came out of the workshop with puzzles to investigate further.
