• key part of being "iterative" rather than "incremental"). While some architectural design will help an application's coherence, starting with frameworks can lead to build in functionality that you will not need, as well as make it really difficult for the product owner to see progress. It is easier to demonstrate a User Interface than a Database API.

Time Box Boundaries

Iterations are different from the usual long-ish planning cycles teams and product owners are used to.

Some teams will want to extend the iteration a day of two to finish the work that is "almost done." The product owner may want the team to finish a task before starting a new iteration. Avoid this. Even though it is difficult to admit that work is not complete, having leaky iteration boundaries opens the door to schedules slipping without feedback, and does not give you the chance to adjust.

Agile methods acknowledge that there is uncertainty, and that Big Planning is rarely accurate; some customers sometimes take the idea of " Responding to change over following a plan " to an extreme, meaning that there need not be a framework for planning. While the "big plan" can change from iteration to iteration, the iteration boundaries provide an essential framework for keeping a project on track.

From a morale point of view, end of iteration reviews are a focal point for the team and the product owners, allowing for a forum where the team can acknowledge small slips and work with the product owner to make adjustments. The longer you put off a review session, the higher the cost of admitting a problem.


(Wrapping Up ) Getting Started

While there is a lot behind an iteration, having your team work effectively with iterations is, well, an iterative process. To be successful the an iteration needs to have a reasonable length, start with a good set of stories, and the amount of work that the team signs up for should match well with the capacity.

When you start off with iterations you may plan for more or less work than fits, or you may find that the stories you are working on are too broad to make reasonable progress on, or that you have not planned for a realistic amount of support work. Working with iterations means that you can take what you learned and strive to do better next time.

Iterations are not an obstacle to having the customer set product priorities. Iterations help both the product owner and the team focus on the most important work, while allowing for adaptation for the unexpected.

If you are new to agile, you may be tempted to adapt the iteration process before really trying it. Agile teams believe in continuous improvement, but it is best to start from an understanding of how the "model" works before making changes.



About the Author

Steve Berczuk is a consultant and developer who works with Agile teams. He has over 20 years experience developing applications, often as part of geographically distributed teams. In addition to developing software he helps teams use Software Configuration Management effectively in their development process. Steve is co-author of the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration and a Certified ScrumMaster. He has an M.S. in Operations Research from Stanford University and an S.B. in Electrical Engineering from MIT. You can contact him at [email protected].


AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.