This chapter covers the following topics:

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.

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.

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):

 

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.

ITERATIONS AND GOALS

Each iteration must focus on achieving a goal that will provide business value to some degree. As the iterations progress, they contribute to an increment that may be deployed for use in the business. As increments progress, they contribute to delivering the overall solution for the project and, in turn, this contributes to the delivery of the predicted business benefits. How these iterations, increments and goals interrelate is shown in Figure 15.4.

 

Figure 15.4 The relationship between iterations, releases and goals

Although the overall release plan may be decided at the start of the project, it is important not to plan too much detail into later iterations, as they may change. All changes should always be tested against higher-level goals to ensure that they are being met.

The benefits of goals

Goals serve to focus the team on what is important. Even with a prioritised backlog as described in Chapter 13, it can be easy for teams to lose focus on what will offer value to the customer. This is where a business analysis perspective can be very helpful. Where possible, goals should be described in line with what is deemed valuable to the customer. Decomposing and working with goals is explained in detail in Chapter 8.

Goals are also helpful when naming iterations. For example, calling the iteration ‘Allow credit card website purchases’ instead of ‘iteration 4’ means that is it very clear that the purpose of this work is to make the credit card purchase section of the website work. There may be other tasks on the backlog, but if those that relate to the credit card processing have not been completed, the goal cannot be met.

The iteration goal also needs to be aligned with the project and release goals. This alignment helps to ensure that the iteration contributes to the goals of the release, the release contributes to the goals of the project, and the intended value to the business is delivered. Agile methods embrace and anticipate change, but sometimes changes that happen during development can mean that the project becomes slightly misaligned with the original intent. When this begins to happen, it is critical to recognise it straight away and decide if further action needs to be taken.

This is especially important where the iteration goals have been set by different stakeholders or customers from those involved in setting the project goals. Indications during early iterations that the project goals are wrong or will not be met, need to be communicated to the stakeholders responsible for the higher-level goals immediately. This is particularly critical where project goals have other purposes (such as being linked to contract payments or dependencies on other projects).

This cross-checking between iteration goals and project goals is one of the ways that agile methods can provide early warning of project issues. Early warning means that there is time to correct, or, if the changes are catastrophic, that the cost of cancelling the project is reduced – it is always cheaper to cancel a project earlier rather than later!

It is not always the case that the iteration goal is decided first. Often, the prioritised user stories will determine the goal. However, the converse is also true – knowing the overarching goal of the iteration may cause some user stories to be ‘promoted’ because it becomes clear that they contribute directly to the goal.

What is important, however, is that the user stories that are delivered provide features that are valuable to the business. This upholds the agile value of ‘working software over comprehensive documentation’.

When setting goals, possible pitfalls to look out for are:

PLANNING THE ITERATION

Before work can begin on an iteration, a degree of planning is required and this should be in line with the agile maxim of ‘Just Enough, Just in Time’. Starting with a properly ordered backlog, the team must agree which backlog items should be selected for this iteration. This means that they must know what resources they have available, and must have sufficient understanding of the work that will be required to satisfy each requirement. The team must have enough information to answer these questions, but as discussed in previous chapters and in the agile principles, there should not have been a lot of up-front work in case a requirement changes or isn’t required. This can be achieved in several ways:

Several factors can affect iteration planning. Many arise at the start of projects, particularly when using approaches that do not cover the whole project life cycle. Scrum, for instance, expects several preconditions to be met before it can begin: there must be an ordered backlog of requirements in place and the team must have the environment, facilities and skills to begin delivering working software in less than one month in duration. In practice, this is rarely the case and teams require time to reach this stage. The backlog needs to be created and there may be technical or architectural risks to be mitigated. There may also be structural or architectural elements required that simply take longer to build than allowed for in a typical sprint. These must all be understood enough before release or iteration planning can begin.

The phase where these essential factors are put in place is often called ‘sprint 0’, but it isn’t a formal part of Scrum and there isn’t a great deal of guidance on how to do it. This means it can be easy to fall into some of the bad practices of traditional development. Business analysis is an important skill at this stage of the project, and the business analyst must ensure that the agile values and principles are still adhered to. The most important thing to remember is that the goal of ‘sprint 0’ is just to be able to start ‘sprinting’; and this requires ‘just enough’ work to be done.

Team velocity

Teams work at different speeds from one another. Velocity is the term used to predict how much value a team can deliver during a defined time frame, based on knowledge about how they have performed in the past. Various measures of value can be used, but a popular approach involves user story points. These are discussed in Chapter 14, along with further detail on estimation techniques and measures.

Knowing the velocity of a team is important for two reasons: first, to be able to give a rough idea of how long in total a project may take to complete; second, to be able to work out how much work should be attempted in each iteration.

To calculate the duration of simple projects, the basic technique is:

 

Figure 15.5 Calculating team velocity

Figure 15.5 shows an example of estimation using story points.

Since units, like story points, are subjective different teams may estimate the same value differently. In other words, one team’s 8 story points could be another team’s 13 story points. This means that story point sizing and therefore team velocity are unique only to that team.

If the agile team is a highly performing team, estimates of velocity can be very accurate, particularly when estimating work with which the team is familiar. However, if the team changes, the velocity needs to be recalibrated. So, to maintain predictable velocity, teams need to remain constant. This doesn’t mean that teams cannot change, but it does mean that when there is a change to the team, we cannot expect the velocity to remain the same.

This method works well for simple, well-understood projects and once projects are well underway. It can be an excellent way to understand team capability and predict future deliveries. However, it fails if the backlog gets too big, where the project is not well understood at the outset or where it is likely that the requirements will change. This is for the following reasons:

The same approach can be used to track how much value the team is able to deliver each iteration, and to help predict the right amount of stories to plan for the next iteration. This can still be helpful when the overall project size is not known, as it helps to optimise the work done preparing stories for the next iteration.

Since velocity is a measure of the volume of valuable software produced within a given timebox (i.e. an iteration), only work that offers value to the business should be included when calculating velocity. Other work carried out by the team, such as technical spikes or management activities should not be counted as velocity. In practice, however, iterations often include other tasks, such as spikes, refactoring, fixing defects, management activities or partially completed stories. Where these tasks deliver genuine value they should be included, but often they aren’t.

A good approach is to allocate 60 per cent of the available effort for story point delivery and ensure that any activities that don’t generate business value are in the remaining 40 per cent. Over time, the amount of non-value-generating work will average out, and the team will have a reasonably accurate estimate of the amount of value they can deliver in an average iteration.

Iteration planning meeting

The iteration planning meeting is a critical meeting for the team and must involve the whole team, including the business analysts. This is important because it is the whole team who will be doing the work so it is critical that they all contribute to the meeting and commit to the outcome. The key business stakeholders should also attend, particularly a business representative such as the product owner. Business analysis skills are important to the success of this meeting; they ensure that the team is delivering the right requirements, and that the project team and business stakeholders understand one another. The purpose of the meeting is to:

The iteration planning meeting is usually held at the start of the iteration and is considered as part of the iteration. It should be after the review meeting for the previous iteration so that any changes can be incorporated within the new iteration. It is an important meeting and, as such, should have sufficient time devoted to it. Founder of Scrum, Ken Schwaber, recommends that 5 per cent of the overall iteration duration should be spent on planning and preparing for the iteration (Schwaber and Sutherland 2014). The meeting is usually divided into two parts.

Part 1

This part focuses on identifying which backlog items² should be included in the iteration. Since the product backlog should already be ordered, the team should start at the highest priority item, estimate how big they think it is and work out whether they have the effort to complete it in this iteration. If so, they continue down the list until there is not enough effort left in the iteration. Some of the estimation techniques discussed in Chapter 14 can be used if necessary.

When deciding which backlog items to put into the iteration, teams must also consider what will happen if all the work planned isn’t completed. Since iterations are often timeboxed, the iteration will sometimes end before all the tasks for a backlog item are finished. For this reason, it is helpful to consider the priorities of the work of the iteration and ensure that the mix of priorities provides some contingency, as discussed in Chapter 9. For example, using the MoSCoW prioritisation approach might mean allocating mainly backlog items with a priority of ‘M’, but also including some with a priority of ‘S’. In the situation where some backlog items need to be dropped, it is possible to defer the ‘S’ backlog items until a future iteration. A good rule of thumb is to ensure that ‘M’ backlog items account for no more than 60 per cent of the total backlog items set for the iteration.

Following this approach also allows teams to include backlog items with a ‘C’ level of priority where they are linked to higher priority backlog items and need little additional effort to deliver, or where they are mitigating risk for higher priority backlog items in later iterations. Since the MoSCoW priority is revisited in each iteration, this is also a way of bringing forward backlog items that will be ‘M’ or ‘S’ in later iterations for the team to start on if they have time left toward the end of this iteration.

During Part 1 of the planning meeting, it is likely that there will have been little work on the backlog items. Accordingly, it is usual at this point for some backlog items to be too big to be completed in a single iteration. Where this is the case, the backlog items (usually user stories) are decomposed in line with the goal decomposition approach described in Chapter 8. Since this involves discussing, adjusting, breaking down and estimating backlog items, it is essential that the product owner and any other significant customers are present. Given the need to collaborate with stakeholders, business analysis skills will be extremely helpful during this work.

At the end of Part 1, the team has an agreed and prioritised backlog of work, and they should be confident that they can achieve them all in the time available. However, the selected backlog items remain at a high level of abstraction so the underlying tasks, and who will complete them, may not be clear.

Part 2

During Part 2 of the iteration planning meeting, the team must further decompose the stories to allow them to start work. However, since there is a prioritised list, the high priority stories should be worked on first and the lower priority stories can be left until later.

For each story to be broken down, the set of individual tasks should be identified and estimated. If individual tasks are being estimated, it is good practice for the team to be responsible for the estimate. Consequently, the estimate can accommodate different skill or experience levels and so the collective expertise of the team responsible for completing the tasks adds to the accuracy of the estimate. At this level of estimation, it is common practice to use hours, days or ‘ideal’ developer days as the unit of measure.

At this stage, it is common for some requirements to be vague and for the team to struggle to break them down fully. Perhaps there is uncertainty about what exactly is involved or perhaps the right technical solution is not clear. To address this, teams create specific tasks to gather information. These types of tasks are often called a ‘spike’ – a short, usually time-bound, task that results in additional information to help the team estimate stories (for example, deeper requirements elaboration or technology investigations). Spikes can exist on the backlog in their own right or they can be added in iteration planning meetings when it becomes clear that they are necessary. The results of spikes will allow existing stories to be progressed or new stories to be added to the project.

The problem with spikes is that they consume effort from the team during the iteration, yet they deliver no business value themselves. For this reason, it is important to ensure that spikes are Just Enough, Just in Time, and are only planned for high priority or high-risk stories.

Possible issues during iteration planning

Issues may arise that cause problems during the iteration planning meeting. Some of the potential issues are:

Product backlog refinement

One of the most important artefacts of any agile team, particularly for business analysts, is the backlog. As described in Chapter 13, there are two main backlogs: the product backlog and the iteration (or sprint) backlog.

The product backlog is first created at the start of the project and comprises the list of requirements that the project stakeholders think they want the project team to deliver. Although theoretically an ordered list, product backlogs are frequently long and, in reality, it tends to just be the stories towards the top that are properly ordered or prioritised.

At the start of an iteration (in the planning meeting described previously), the team should examine the product backlog with the product owner and assess the top items – those of the highest priority – to create the iteration backlog that will shape the work for the forthcoming iteration.

However, that implies that the product backlog is still up to date and accurate, and, sadly, that’s not always the case. The project team concentrate on the iteration; the product owner helps them (and often has other responsibilities) and the poor old backlog can get a bit neglected.

This is where the process of ‘product backlog refinement’ is needed. This is the practice of preparing the product backlog for forthcoming iterations, by doing some or all of the following things:

These backlog refinement activities are shown in Figure 15.6.

This task should be carried out with the product owner and business stakeholders, but does not always need to involve the whole team. It is a task that is ideally suited to business analysts. However, there some constraints are important to consider:

Where these constraints need to be broken or challenged, then a more formal and classic approach to change management or change control needs to be applied.

Managing and visualising progress

In order to properly plan, manage and track the work of the team, it is important to communicate what is happening. Agile boards are a popular technique derived from Lean manufacturing to help visualise and manage workflows. They can be physical boards or tables, or may be implemented using software tools.

The board is constantly updated through the iteration by team members, allowing them to self-organise, spot problems early and help one another. It is the focal point for the team, providing the raw material for daily meetings and helping to provoke discussion. Since boards are often on display in the team area, they also enable transparency within the team, which is a core pillar of Scrum (Chapter 5).

The agile board is particularly important for Kanban and its derivations, but can also add value to other agile methods. An agile board for an iteration is shown in Figure 15.7.

 

Figure 15.7 Agile board

Each row on the agile board is a user story, taken from the product backlog and agreed by the team to be developed in this iteration during the iteration planning meeting. Each user story is turned into multiple task items, which all start in the ‘To do’ column and gradually migrate toward the right as they progress. In some methods (for example, Kanban), the number of tasks allowed to be in each column is limited, and team members work from the right to the left to unblock columns and encourage flow.

The columns typically found on an agile board are:

Stories	This means the user story to be delivered (‘As a user I want to …’).
To do	This is the set of tasks identified to complete the user story.
Work in progress	This refers to any task that is currently being worked on by a member of the agile team.
To verify	Once complete, tasks must be tested or reviewed. In some teams, this is a formal ‘approval’ stage. For software, the test stage could be a separate task.
Done	Task cards move into this column when they are done. A user story can only be considered done once all the task cards within the row for that story have been moved into the ‘done’ column, and it is agreed that the ‘Definition of Done’ for the story has been achieved.

Projects often customise their boards, and can use colours, shapes, codes or extra columns to add information.

Agile boards also support other elements of agile development. Since all the tasks outstanding are visible, team members are encouraged to choose their own tasks. They should first look for tasks that will create space on the board (the tasks toward the right, such as testing or reviewing), but should also select tasks that suit their own skills and development requirements. This is central to the ‘whole team’ concept, and the ‘self-organising’ nature of agile teams.

The board should help the team members to see if there is a skill shortage within the team or whether the team is unbalanced in some way. This may require others to join the team, possibly to provide additional skills.

At the end of the iteration, the stories that have been completed – those that have all their sub-tasks in the ‘done’ column – can be added up and, if accepted by the business owner, can be used to update the team velocity.

Agile boards also support methods without timeboxed iterations. In those methods, increments are released when a set number of stories are complete. This might be important in support life cycles, where the cost and impact of updating a version will need to be worth the potential benefit.

It is common for new tasks to be identified as the work progresses and the team learns more about the stories. This is why it is important that the team works on the higher priority stories before starting lower priority stories.

Dealing with change

The second agile principle states: ‘Welcome changing requirements, even late in development.’

Change is inevitable, even with simple projects. Many agile practices and techniques have evolved specifically to make dealing with change easier, and more likely to result in increased value to the customer. That’s why it’s important that agile teams are prepared for change, seek it out and help to harness it for the benefit of the customer.

This is embodied nicely in another principle: ‘Simplicity – the art of maximising the amount of work not done – is essential’, and the maxim Just Enough, Just in Time. When things change, work done against the old requirement is wasted and represents unnecessary time and/or cost.

Agile teams have many factors at their disposal to cope with change, such as iteration length. Given that teams try hard to do as little work as possible on requirements until they formally enter an iteration, it follows that changes to things not yet started will have low impact on the team. With short iterations, it will never be terribly long before the customer has an opportunity to change the team’s focus. And in the worst case, where the change is so significant that the iteration must be scrapped, the maximum amount of time lost will be limited to the time already spent on this iteration.

Setting a clear focus on iteration goals is also critical to coping with change. At the end of an iteration, the customer should be able to use the product that has been delivered. That means that it should be sufficiently tested, integrated, documented and supported. While the Agile Manifesto values working software over comprehensive documentation, there still needs to be enough documentation and support to allow the software to be used by the customer.

Agile teams should be able to make a clean break at the end of each iteration, even when it isn’t planned to be the final iteration. That means that if the customer decides that the version demonstrated meets their needs, then the project can finish. There and then. Not after another three iterations while we finish off the documentation, write a support guide and fix all the bugs we didn’t have time to fix during the last iteration.

This gives the customer the ability to stop work early, potentially saving money, but in larger organisations, it also allows business calls on priority to be acted on quickly. If there is a higher priority project for the agile team to work on, it makes sense that they can complete their existing commitments quickly and move on.

Non-timeboxed Iterations

Most of this chapter focuses on iterations that are time bound, and the team decides what work can be done in the available time. That’s because most agile methods work on some kind of timeboxed iterative model. However, this isn’t true of all methods, and some, such as Kanban, are bounded by other factors, such as Work Completed.

However, many of the techniques and situations described are just as applicable to non-timeboxed iterations. They are still agile methods, so still place value on the same manifesto statements and principles as the others do.

With non-timeboxed iterations, the team must decide what criteria they will use to decide when to release a version to the customer. This could still be goal based (and each goal may take a different amount of time to be delivered) or it could be based on the number of stories that are ‘Done’.

One advantage of goal-based iterations is that goals themselves are rarely the same size. That means that time-bound teams will find themselves either stretched at the end to fit everything in, or will have completed some stories that aren’t really helping the goal. Goal-driven teams deliver when the goal is complete, which could be quicker or slower than other goals. On the other hand, the continuous, production line nature of some methods can make it feel like the work never ends.

MANAGING AND MONITORING THE ITERATION

Agile teams use a number of techniques and approaches when managing and monitoring their iterations. These approaches typically have some attributes in common: they embody one or more of the Agile Pillars of Transparency, Inspection and Adaptation (see Chapter 5); they require Just Enough, Just in Time; they encourage continuous improvement; and they involve the whole team.

Some common techniques are daily stand-up meetings and burn charts.

Daily stand-ups

A common agile practice is the daily stand-up meeting. This meeting, which originated from Scrum and XP, is one of the more popular techniques for managing ongoing work and has been widely adopted outside agile development. It is fundamental to maintaining the heartbeat and rhythm of the iteration, and is a way of ensuring that pace is being maintained and regular communication is also taking place.

The daily stand-up is facilitated by the Scrum master (in Scrum) or by the iteration lead or team leader, however, the facilitation skills of a business analyst can prove very useful in these meetings. It is crucial that the whole team is involved and, to encourage participation, the meeting is usually limited to 15 minutes and conducted standing up – partly to ensure it is kept short, but also so that there are fewer reasons to prevent it happening. You don’t need to book a room if you can stand around the agile board to have your meeting! Each team member is asked the following questions:

There is some debate about what the ‘best’ questions are (and there are many more versions than those stated above). However, the intent of the daily stand-up meeting is to focus the participants’ attention on whether they are making the progress that is expected, and on asking for help for anything that might delay or prevent progress. It is a meeting of peers, not a management progress report, and should feel like an important part of the team’s day.

The meeting focuses on the identification of issues not the solving of them. In Scrum, it is the responsibility of the Scrum master to remove any impediments, and they focus on that following the meeting, not during it. Similarly, if one member of the team has dependencies or issues regarding the tasks of another team member, they should discuss these with each other following the meeting. If they cannot resolve an issue, it can be escalated to the Scrum master as an impediment to team progress.

Monitoring and reporting progress

The use of agile boards has already been discussed as a good way to record and present progress, but they only show the present situation. Burndown and burnup charts are also used to communicate team progress. Burn charts can have value at several levels, within iterations, for particular increments or across the whole project. Typically, burndown charts show progress within an iteration, while burnup charts show progress across iterations towards project or release goals. However, this is not a hard and fast rule.

Burndown charts

A burndown chart plots the amount of work, usually in the form of stories, tasks or story points, that has been delivered by the team as they move through the iteration. Unlike an agile board that just shows current status, burndown charts show when the work items were delivered, and can provide useful information on how the team is working. Figure 15.8 shows an example burndown chart.

 

Figure 15.8 Example of a burndown chart showing story points

The Y-axis shows what has been delivered and the X-axis shows the iteration timeline, usually in days. Teams use their burndown chart for three main reasons:

There may be problems when the user stories are quite large and take most of the iteration to complete, as it looks like the team is making slow progress and no stories are being delivered. This is made worse where a story is not quite finished by the end of the iteration because it shows on the chart that the whole story has not been delivered rather than that the team had completed most of the work. This situation may be avoided if user stories are appropriately sized and are small enough to show progress.

A second issue that burndown charts can expose, even with correctly sized stories, is where the priority of the customer (product owner) is being used to drive team behaviour. This is evident where the agile team is not working on the higher priority user stories first, moving towards the lower priorities as the iteration draws to a close. This approach shows regular deliveries on the burndown chart, and the customer knows that the work already completed was their highest priority work.

However, it is common (particularly with teams who are struggling to adopt the agile mindset) for teams to start the iteration by breaking down all the stories and sharing them out amongst the team. Early on, most stories have someone working on them. Because there are fewer team members in each story, each story will take longer. At some point (perhaps quite late in the iteration) some stories will be completed, and show as progress on the burndown chart. But, since the stories were all started at the same time, the first stories to be completed might not be the highest priority ones. As the iteration draws to a close, some stories might not be completed yet and it is possible that they are the higher priority ones.

Burndown chart showing work remaining

An alternative approach to recording progress and reporting burndown, is to burndown tasks rather than stories, and to record work remaining rather than stories completed. In this method, tasks are identified and estimated in hours during the iteration planning meeting. These tasks are then totalled and the estimated hours of work for the iteration plotted on the Y-axis as shown in Figure 15.9.

This approach offers some benefits. If tasks are sized relatively small but not too small (3–12 hours), then team members see progress frequently. Tasks smaller than a couple of hours are too small to bother recording, though of course they do add up.

The downside to this approach is that it requires the whole iteration to be broken down to quite a detailed level at the start of the iteration, and since tasks do not represent the delivery of customer goals, it is less clear whether the team is on track or not. It is important for the team to update the time remaining on each task at the end of each day. While the burndown chart may not show any progress, this approach provides a more accurate indicator of how close the work is to completion.

 

Figure 15.9 Example of a burndown chart showing remaining effort

Burnup charts

Another representation is a burn chart that tracks progression towards a release goal. The same measures of velocity can be used but the number of iterations is used instead of days along the X-axis. The Y-axis is typically some measure of progress, such as stories or story points, but the chart starts at 0 and works up rather than down. An example is shown in Figure 15.10.

This chart of velocity scores throughout the life cycle and also allows for the validation of up-front estimates and the correction of final delivery targets. The target line shows what the customer expects to be delivered. As the iterations proceed, the angle of the progress line can be extrapolated to see whether the target line will be hit when expected. The accuracy of the prediction will depend on the accuracy of the velocity recorded in previous iterations.

This can be helpful for two reasons:

 

Figure 15.10 A burnup chart showing progress of iterations

Either situation allows an early indication that a project may require some intervention: typically additional resources (velocity), additional time or a reduction in scope.

REVIEWING THE ITERATION

At the end of the iteration, two important things happen:

Iteration review (show and tell)

The ‘show and tell’ meeting is a critical milestone for the team and customers. The purpose of the session is for the development team to present back to the customer or product owner what they have delivered during this iteration; and for the customer to decide whether the acceptance criteria for each backlog item has been met.

The customer gets to see progress so far and can provide feedback, thoughts and ideas to the team to help them in future iterations. This may result in changes to the backlog or the creation of bug reports for defects in the current version.

These meetings are mainly for the benefit of the customer, so care must be taken by the team not to get bogged down in technical detail. The team should ‘show’ the product in action, demonstrate the functionality, and ‘tell’ them what the customer or user experience will be like. The aim is to make the development work come alive in the user’s eyes. They are intended to be interactive, with the customer feeding back what they are thinking. All feedback should be captured and responded to.

An experienced business analyst can play a critical role here, helping the customer to understand what they are being shown (especially if it is an early, unpolished version) and helping the development team to avoid too much technical detail.

The whole-team practice of agile means that the person closest to the development is often best placed to present the detail; the ability to take pride in your work and be recognised for your contribution is an important motivating factor. It should not be the team lead or project manager claiming all the glory!

Show and tell sessions are an important part of the agile process but can often fail due to a lack of planning or poor facilitation – areas where contributions from a good business analyst can be invaluable.

Retrospectives

One of the most important meetings in agile iterations is the iteration retrospective meeting. It directly addresses the core agile value of responding to change and the principles of reflecting and becoming more effective.

The realities of agile projects are that very little is completely predictable or already perfect. Retrospectives give teams the opportunity, in a safe environment, to reflect on how they performed and decide on any changes they wish to make. To provide a safe environment for honest reflection and feedback, only the direct team members should attend.

Retrospectives should take place after each iteration and all team members should attend. Retrospectives should also be held following major releases or at the end of the project. These retrospectives are often longer and more intensive. They can occasionally be helpful if an unexpected event changes the situation, for instance, if an iteration has to be abandoned.

A well-conducted retrospective can help the team to focus on the significant events and help them to remember what happened. This can require good facilitation, so business analysis skills are particularly helpful.

Running a retrospective

Many development teams simply discuss some variation of these three questions during retrospectives, as shown in Figure 15.11.

This is a good start, but more structured approaches can lead to far greater value. In their 2006 book, Agile retrospectives: making good teams great, Derby et al. define a simple framework for conducting retrospectives that draws on many of the skills possessed by business analysts. They recommend a focused facilitation approach to create the right environment to elicit the right data, analyse what the team are saying to establish patterns and trends, and identify a small set of high-impact but manageable changes. The key is to pick two or three important changes rather than try to fix everything possible.

 

Figure 15.11 Common retrospective questions

There are two further questions that should be asked, but are often omitted:

As projects mature, the precise mix of skills and experience required may change. This could mean that the team is too big or too small for the next iteration, or perhaps the team was struggling with some technical detail and would benefit from some consultancy or specialist training.

One key advantage of agile approaches over traditional methods is the ability for agile teams to finish early. Because they focus on delivering working solutions and highest priority work first, it is possible to reach a stage where the project could continue into the next iteration, but the customer is actually quite happy with the product as it is. Where this is the case, the team should be able to stop, resulting in a cheaper product for the customer.

This feature of agile teams is especially important in larger organisations, where the main benefit is that the team can now start on new, higher priority work earlier – they are not committed to the original end date. This does, however, depend on the team being disciplined enough to have completed all necessary non-functional requirements, general and technical requirements.

Why retrospectives fail

The biggest danger in a retrospective is that is becomes accusatory and defensive rather than supportive. Team members become more concerned with protecting their reputation than honestly examining how the team performed. The single most effective thing that can prevent this is to adopt a no-blame culture during the retrospective – and to mean it. That might mean excluding managers or team leaders from the meeting, or finding ways to permit anonymous feedback.

Some pitfalls to watch out for:

THE ROLE OF BUSINESS ANALYSIS IN AGILE ITERATIONS

Business analysis is a critical skill set in many of the key stages of an iteration. Even in methods where dedicated business analysts are not mentioned, there are key artefacts or practices where business analysis skills and mindset can make the difference between success and failure.

Even where the team does not have a dedicated business analyst, there should be business analysis skills in the agile team. Not necessarily in each member of the team, but in enough people that the value of business analysis can be properly harnessed.

The presence of business analysis experience in agile teams can help them to keep a focus on the customer and the business needs. Seeing goals from the customer’s perspective, and being able discuss the work so that it makes sense to the customer, can be essential for maintaining good working relationships and enabling collaboration.

Several of the practices in iterations require business analysis skill, particularly those relating to requirements and prioritisation. The backlog is a clear example; poor business analysis at any level can result in the wrong items being put on the backlog or in stories being split in unhelpful ways, such as functional decomposition.

Refining the backlog is a task that is often neglected or rushed, yet it is one where a business analysis approach is very important. The ability to critically assess stories, apply strong prioritisation and describe requirements in a way that reflects what is needed rather than a pre-defined solution, is extremely important. Sometimes, the customer or product owner can fulfil the business analyst role. However, this is often not the case, and even where it is possible, it is difficult to be both customer and analyst.

The contribution of business analysts

Where organisations have dedicated business analysts, there are a number of ways in which they can make an important contribution to the success of agile iterations, either as a full-time member of an agile team, or in a part-time or ancillary capacity.

Although virtually all agile methods advocate a dedicated customer representative (often called the product owner), who is preferably co-located with the development team, in practice it is often the case that this does not happen. Either the customer is not co-located or they are not dedicated, and sometimes neither is the case. Teams often look to a business analyst to fulfil this role.

Organisations that employ business analysts will also tend to develop more complex products. Navigating this complexity, particularly where there are high-level project dependencies, intangible business outcomes or strategic requirements, is a natural space to call upon a business analyst. And where the organisation is expecting the project delivery to follow agile principles, it is important that the business analysts understand agile well.

Another factor that can complicate things is where other members of the overarching project or programme team do not understand agile well. They may have come from a background of classic waterfall programme delivery and challenge some of the agile approaches. Business analysts are well placed to help re-assure them and also help the agile team know how to interact with them. This might mean changes to how the high-level requirements are described, or to how the business outcomes and high-level milestones are phrased.

Agile methods tend to be optimised for the development of code. They tend not to worry too much about the work that is required to get the backlog in order, nor to manage the integration, rollout and business readiness tasks. Many business analysts work on ‘funnelling’ in requirements to the backlog and ensuring that all the elements of the business change are managed.

CONCLUSION

Iterations are the core element for all agile development methods, and the role of business analysis is important to their success. The quality of the product backlog, and the ability of the team and customers to properly break down requirements to goals delivering business value are extremely important; these are areas where strong business analysis skills are needed.

NOTES

1 This is one of the original agile principles – http://agilemanifesto.org/principles.html.

2 Backlog items is the term used to describe the work that the team need to deliver within an iteration. This phrase encompasses requirements and user stories.

REFERENCES

Deming, W.E. (1982) Quality, productivity, and competitive position, later published under the title, Out of crisis. Cambridge, MA: MIT Press.

Derby, E., Larson, D. and Schwaber, K. (2006) Agile retrospectives: making good teams great. Dallas, TX: Pragmatic Bookshelf.

Schwaber, K. and Sutherland, J. (2014) The Scrum guide. ScrumGuides.org. Available from: www.scrumguides.org/scrum-guide.html [20 December 2016].

FURTHER READING

Pink, D.H. (2001) Drive. Edinburgh: Canongate Books.

Shore, J. and Warden, S. (2007) The art of Agile development. Sebastopol, CA: O’Reilly Media.