15 Planning and managing iterations
This chapter covers the following topics:
• the iteration;
• iterations and goals;
• planning the iteration;
• managing and monitoring the iteration;
• reviewing the iteration;
• the role of business analysis in agile iterations.
Introduction
This chapter explores the work conducted within the iteration, the fundamental element of an agile project. There are many aspects to understanding how an iteration works, including planning, monitoring and reviewing the work. The techniques and approaches used during these activities are discussed below. The key artefact for an agile project is the backlog. In Chapter 13, we discussed this in the context of a solution so referred to the ‘solution backlog’. Here, the focus is very much on the delivery of the software product so we refer to the ‘product backlog’ or often, simply, the backlog. However, the concept of a central repository of work items, such as requirements and user stories, remains the same. As such, the backlog is an artefact that business analysts in agile teams will become very familiar with.
THE ITERATION
Many agile methods are described as iterative and incremental, so it is important to understand what these terms mean.
• Iterative: the work evolves through elaboration and successive refinement.
• Incremental: the product is delivered in several parts, with each part building on the last, usually adding new features or qualities.
Often, the delivery of the increment coincides with the end of an iteration, but in some projects, particularly where they are large or complex, it may take several iterations before an increment is ready for delivery. This is where the working software delivered at the end of an iteration does not offer sufficient functionality for it to be deployed.
The iterations defined by the various agile methods share many common features, though they may use different terminology. This chapter will define and discuss the features of an iteration in a method-agnostic way, and will describe a range of techniques and practices to plan, manage and track the iteration. Business analysis has an important role to play throughout, and, in some cases, active business analyst involvement is critical to success.
Iterations have a set of typical attributes that are described below.
• Goal: some reason or purpose for the iteration to exist. The iteration should do something and have something to show for the work at the end. There should be clear business value.
• Plan: the steps required to meet the goal should be clear and agreed with the team, the customer and other important stakeholders. This includes how the work will be tested and accepted. By planning only this iteration in any detail, the team is mitigating against the risk that future requirements (or goals) will change.
• Implement: the steps agreed are done by the team, with a focus on achieving the goal. For software products, this may appear like a mini-waterfall of steps for each work item, with all the activities from requirements capture to integration and testing required.
• Monitor and review: even within an iteration, progress is reviewed, often daily, and the team should know whether the goal is still achievable, and desirable. This progress should be visible and transparent, and often uses physical components like boards, sticky notes and wallcharts. This means that both the team and other stakeholders can monitor progress.
• Review the iteration: continuous improvement is a critical element of agile development, so agile teams take every opportunity to identify things to do better, but especially at iteration boundaries. This includes acknowledgement of things that went poorly, but it also means understanding that the project itself will change and evolve; and that may require the team to change its behaviour or composition.
• Decide the next iteration: the team, with the customer, decides whether there will be a further iteration and, if so, how it should happen. This may include making changes identified in the review.
A simplified iteration cycle incorporating these attributes is represented in Figure 15.1.
Figure 15.1 Cycle of an iteration
Iteration
This cycle may be familiar to business analysts as it is a variation on the Shewhart Cycle, popularised by W. Edwards Deming (1982), with his Plan-Do-Study-Act wheel developed in the 1950s. Agile teams often work at a high level of intensity during an iteration and are focused and optimised to react to change.
Figure 15.2 shows a slightly different view of an iteration, identifying some of the activities common to iterations using more familiar terminology: ‘prepare backlog’ and ‘iteration planning meeting’ are forms of planning; ‘daily stand-up meetings’, ‘show and tell’ and ‘retrospective’ are types of review. These activities are described in further detail later in this chapter.
Figure 15.2 Iteration activities
In agile projects, the iterative process is often layered and iterations can be considered to exist at several levels of abstraction (see Figure 15.3):
• micro-increment level (for example, daily iterations);
• delivery level (for example, two week iterations);
• project or architectural level (for example, phases like business case development; inception or construction, that could take several weeks or months);
• strategic or release level (for example, major product releases).
Figure 15.3 The layered approach to iterations
Several approaches (particularly those focused on scaling or enterprise-level projects like SAFe, DAD or the UP) address some of this layering specifically. But even those that do not (such as Scrum or XP) still provide some approaches and practices that teams can use at any level of iteration.
This chapter covers the most common level of abstraction – the delivery layer, which is shown in Figure 15.3 above. This typically involves short iterations (two to four weeks), each of which delivers a version of the overall product and culminates in a final increment or release after several iterations. These iterations are called ‘sprints’ when using Scrum.