Driving continuous improvement with Sprint Data

1. Introduction
2. Context
3. Collecting Sprint data
4. Using Sprint data
5. More data and usages
6. Conclusions

Introduction

In Agile or hybrid project management methodologies, it is common practice to divide the project into iterations lasting between one and four weeks. These iterations are commonly referred to as Sprints.

During a Sprint, the project team commits to completing the activities agreed upon during the Sprint Planning (or Iteration Planning) phase. In addition to executing planned tasks, the team is also responsible for identifying potential impediments, such as lack of resources or inefficient communication, that may prevent the completion of these activities within the Sprint.

The Project Manager or Scrum master is responsible for enabling the team to detect operational issues, supporting the decision-making process, and ensuring that the team is empowered to implement appropriate solutions.

To support these processes it is possible to leverage the information generated by the development team as they carry out each iteration.

Context

To illustrate how Sprint data can be used to help identify issues and define appropriate solutions, let’s consider the following scenario:

We are part of a team consisting of two developers and one tester, tasked with developing a new software solution for the company. Before starting this project, the team attended a training course on Agile frameworks and methodologies and decided to adopt the following practices:

• Estimate activities using Story Points;
• Use a board to track the status of Sprint tasks (see Figure 1).

Collecting Sprint data

During a Sprint, the team works to transform a set of requirements, commonly referred to as User Stories, into deliverables. Throughout the process of creating these deliverables, the team naturally generates a range of information that can be collected and used to support the continuous improvement of the project team and to help identify operational issues.

The amount of data that can be collected from each iteration is potentially infinite. Therefore, it is important to determine which data, if preserved, can effectively support the following processes:

• Identification of team operational issues;
• Decision-making;
• Continuous improvement.

As a starting point, as shown in Figure 1.1, it is sufficient to track the total number of story points associated with each column on the board. In this case, the following information should be recorded:

• Sprint number (the start and end date of the “Sprint” can also be written here with the sprint number);
• Story points in the “To Do” column;
• Story points in the “In Progress” column;
• Story points in the “Ready to Test” column;
• Story points in the “Testing” column;
• Story points in the “Completed” column.

This information can be easily stored in a shared spreadsheet accessible to all team members (e.g, on Google Sheets or Excel). The document can then be archived along with the rest of the project documentation. By doing this, the document can also be reviewed when the project is closed to inspect which actions a team has taken to solve a problem that another team is currently facing. Although projects are always different and not necessarily an action that worked for one team may work for another, reviewing other teams’ corrective actions may help identify solutions that are appropriate.

Using Sprint data

After completing a few Sprints, at the end of each iteration, we can use the information from previous iterations to help identify potential areas for improvement. By analyzing the data shown in Fig. 1.1, the team can, for example, deduce that:

Through this, the team has also the opportunity to verify whether the corrective actions previously implemented have had an effect, or if it’s necessary to further analyze the issues in order to identify more effective solutions.

More data and usages

For each iteration, the amount of information that can be collected is potentially unlimited, but not all of it is necessarily useful for the process of continuous improvement.
For example, it might be helpful to track the number of bugs that emerge when the tester verifies the functionalities implemented by the developers, in order to assess whether there are issues related to code quality or requirement definition. On the other hand, tracking how many calls the team makes during each iteration may not be particularly useful.

To avoid making the storage of “Sprint” data a complex task it’s important to involve the team to assess which metrics and information can actually help identify issues that could prevent project activities from being completed within time, quality, and cost constraints.

As a general rule, the data mentioned in the previous chapter should always be archived. If additional information is to be included, writing down all the information in the document should not take more than 10 to 15 minutes.

The data collected during each Sprint, such as that shown in Fig. 1.1 and Fig. 1.2, can also be used to generate visual charts like “Burnup” or “Burndown” charts or to calculate the team’s average and median Velocity in Story Points.

Conclusions

After aligning with the project team on which information from each iteration should be archived, this data can be used to help identify operational issues and keep track of the corrective actions applied.
This continuous improvement process allows the team to detect the various obstacles that could prevent successful completion and to promptly apply corrective measures, which can then be evaluated in subsequent iterations.