In an agile project the team is group of people delivering the application code. This includes developers, testers, designers, etc. The product owner, sometimes referred to as the customer, is the person specifying the functionality that the team will deliver and the priorities. The product owner specifies what will be built and the team decides how to build it.

Iteration Overview
In an agile project, an iteration is a fixed period of time during which a team implements a set of features, which result in a shippable increment of the product or project. This period of time is referred to as a Sprint in Scrum. XP refers to a weekly cycle. Regardless of the name, the key features of an agile iteration are:

• It is time boxed. There is a fixed start and end.
• The amount of work that is planned to be completed during the iteration should not change during the iteration.
• It starts with a planning activity.
• It ends with a review activity.
• At the end there is a shippable product or project increment that can be refined in future iterations.

• Commit to a list of items.
• Work on the list.
• Review what was done.

Iteration Activities
During an iteration, the key activities are:

• Estimating and Planning
• Execution
• Review

Issues with Iterations (and Solutions)
While the concepts around iteration are simple, teams and product owners often have some concerns about how well a time-boxed development cycle will fit into their process. Typical concerns are around the areas of setting priorities, scoping work to fit into an iteration, and the practicality of defining a fixed set of work when there are support issues to address. It's possible to adhere to constraints of an iteration and address these issues.

Prioritizing
Iterations force product owners to decide what the most important work items are. In many organizations features are organized into large buckets like "priority one" and "priority two." The reality is that people can generally work on one item at a time, and even if you have all "priority one" tasks, they will be worked on in some order.

By allocating work to an iteration, the product owner has the power to define the order explicitly. Prioritizing individual items can be difficult because a product backlog can be very large. From a practical point of view a product owner need only define strict priorities for work that needs to be done in the next couple of iterations. Coarser buckets are fine for items beyond that.

Another common challenge is that a product owner may not feel like she has all of the information to make a decision that one feature is more important than another when both need to be in the end product. When using iterations, the cost of working on a given feature is smaller than with a non-iterative project; you can decide on one priority and change your mind the next iteration.

With an agile project you move in a direction based on current knowledge, and since iterations are short, the decision does not matter as much as it would should you be planning for a 3-6 month release cycle. The key to assigning work to an iteration is to acknowledge that the difference between 2 items may be quite arbitrary. And you can always reprioritize when the next iteration starts.

Customer Support
While agile teams strive to reduce defects most organizations have to support users while doing new development. Product owners can be frustrated by the restriction that the iteration backlog should not be changed once an iteration starts, as this may lead to newly discovered urgent issues would being put off, reducing the ability of the team to deliver business value.

• Think about the priority. Is the problem something that users need a fix delivered before the end of the current iteration, or can it wait? If an item won't be released or deployed before the end of the iteration, it probably should not be added to the iteration mid-stream. When something is truly urgent, remove something else from the iteration backlog to make room.
  
• Allocate time for fixes based on past history. The purpose of a fixed iteration backlog is to manage expectations. You can allow a fixed amount of capacity to address urgent issues. Everyone needs to be aware of how much effort is spent on new issues, and raise concerns when the amount of new work exceeds the planned capacity. And since there is a fixed capacity for new work the product owner still needs to prioritize what that capacity is used for.
• If Planning for urgent issues does not appeal to your organization, at least track the work as added work in a burn down chart. The impact of the added work on the deliverable end date will then be visible early, and having data on the impact of new work to share at an iteration review will the team and the product owner move towards one of the planning approaches.
• If there are significant issues that need to be addressed that will have a serious impact on the iteration plan, then acknowledge this by stopping the iteration and plan a new iteration to allow for the new work. If the added work is truly more important than new development, acknowledge it.

• Try to focus on the smallest non-trivial end-to-end slice through an application. For example, "Look up flight schedules between 2 cities" rather than "book a flight." This will also help you develop tests, as smaller features are easier to test completely.
• Develop in vertical rather than horizontal slices. Don't implement stories by application tier. (This is also a 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.

(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.

Comments (0)

Write comment

Show/hide comment form