the team reviews their work with the product owner. The review should be quick and informal, and form a basis for a conversation between the team and the product owner about how the iteration went, and what should happen in the next iteration. The review is an opportunity for all of the stakeholders to look back on the iteration as a whole and understand how to do better.
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.
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.
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.
The "fixed work" rule of iterations is not meant to set up a wall between the team and the product owner. Rather, it forces the product owner to address the priority of any new work and its impact to the original commitments. Adding work to the backlog mid-iteration means that it will be more difficult for the team to deliver the work that it already committed to, and makes it difficult for the team to manage expectations with the product owner.
If you are in a situation where the same team is doing support work and new development, there are a few strategies that are true to the spirit of iteration, but still allow for changes:
- Think about the priority. Is the problem something that