- 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.
There is nothing inherent in an agile iteration that makes the team less responsive to the needs of the business. Rather, iterations help the business to understand the impact of change more quickly than other approaches
Development teams often wrestle with the defining tasks that can be done in a short iteration when they are used to thinking of longer projects. Customers have difficulty thinking of meaningful "features" that can be completed in an iteration. Some insist that it is impossible to break work down in a way that allows for anything to be done within the length of an iteration cycle.
Thinking about features that fit into an iteration requires a change of mindset. Agile projects start with the idea that change is inevitable, and agile teams have engineering practices that make change quick and easy. Also, the benefits of agile are that a product owner gets to see something that works (somewhat) while it is still in progress.
Scoping work to fit into iterations is one of the harder things for teams to do, but it is also where you get the most value of iterative development. By iterating you validate project is going in the right direction while you have the ability to make corrections. Iterative development also allows you to decide that what a feature is usable before everything you thought you needed was implemented, thus allowing you to save effort.
With some thought and creativity you can break down almost any feature into something that shows functionality with enough fidelity so that a product owner can decide if the feature is what she really wanted, of if additional requirements are really necessary.
When defining stories or features:
- 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