Getting It Right While Getting On With It

Reading Time: 5 minutes

Fixing Defects from Completed Sprints

The development team here at DistributorCentral has recently adopted Scrum, an Agile methodology for managing team workflow. Scrum was created to address challenges that were common to teams working on large software projects under then standard project management practices.

The authors of Scrum recognized that many software projects aren’t well suited to a rigid one-way workflow where all the questions are answered up front and all development is completed before any code is released.

Scrum “closed the loop” so that features of a project could be worked on in an iterative fashion over defined time periods called sprints. At the end of each sprint feedback is gathered and the unreleased code is evaluated to see if it is ready to be released. If it’s not ready then issues (work orders) are entered for the improvements and prioritized in a list known as the backlog. The next sprint is filled with issues from the backlog and the next iteration begins.

Part of the evaluation process for our team involves an internal testing environment where our staff previews the changes we’ve made. Shortly after we started this internal testing we encountered a question that most Scrum teams grapple with eventually:

How do we manage defects on issues that were completed in a previous sprint while completing our current sprint successfully?

Defects are any feedback on the code in testing that might prevent it from being ready to be released. These include incorrect behavior, errors, misunderstood requirements, edge cases, any other category of just-not-good-enough.

We don’t call these bugs because we reserve that word for describing issues on code that is already released and in use. The workflow for bugs is much simpler, fix it A.S.A.P.

Possible Solutions

Some preliminary research indicated that there are a few ways other teams have approached this problem.

1. Adding an issue for the defect in the backlog for a future sprint

If there is such a thing as Scrum orthodoxy, this is it. When any change needs to be made that is outside the scope of the current sprint (in progress) a new issue is created in the backlog, prioritized and selected for work in a future (usually the next) sprint. This includes defects on code in testing.

This approach may work well for large projects with several sprints in-between releases, but for a small team that desires to release new features and establish a develop-test-release cadence this is rigid and slow.

Pros:

The scope of the current sprint remains unchanged.
The defects are prioritized.
An explicit decision is made to correct them by selecting them for a future sprint.

Cons:

There is a sprint sized lag between when the defect is found and when work may begin on it.

2. Adding an issue for the defect in the current sprint

As in the first approach a new issue is created for the defect, however instead of putting it in the backlog it’s added and prioritized within the current in-progress sprint. Whether the team bothers to estimate the defect or not, the size of the sprint changes.

Pros:

Work on the defect begins sooner.

Cons:

Teams have more work to do in the same amount of time. This might cause pre-planned work to be left uncompleted at the end of the sprint. Some teams may be tempted to under-fill their sprints to leave room for defects to be added.

3. Swapping in an issue for the defect in the current sprint

Disciplined teams might drop a similarly sized issue out of the current sprint when the new defect issue is added to it.

Pros:

Work on the defect begins sooner.
The size of the sprint remains constant.

Cons:

Sprints start to fragment and lose their cohesion. Teams might be tempted to change the length of their sprints to the size of the related work. That makes it harder to get on a good cadence.

4. Reopening the issue from a completed sprint and moving it into the current sprint

If any testing occurs on issues inside a sprint you may be tempted to treat defects on issues that were completed in a previous sprint the same way. So instead of creating a new issue the existing one is added back into the current sprint.

Pros:

Defect tracking is grouped with the initial issue.
Work on the defect begins sooner.

Cons:

It might be difficult to identify which issue caused the defect.
Issues that flow backwards could be confusing and it can be difficult to get a complete picture of work in progress in a system that supports this kind of backwards workflow.

5. Handling defects outside of the sprint

Some teams stop what they are working on and fix defects immediately, either without creating any issue at all or creating an issue in a separate board.

Pros:

Work on the defect begins right away.
The size of the sprint remains constant.

Cons:

The size of the sprint remains constant, but the amount of time developers have to work on the sprint has decreased. In some ways this is just an accounting trick.
It can be difficult to track defects and get a complete picture of work in progress.

Our Solution

None of these solutions seemed like a good fit for our needs so we’ve come up with what we think is a novel approach.

When planning for a new sprint we add and estimate an issue for Testing Support and Defect Fixes. This issue is prioritized above any other work in the new sprint. The estimate is a critical part of this solution and it serves two purposes.

It is an indicator of the team’s confidence in changes from the just completed sprint.
It blocks out time in the sprint for the team to actually deal with defects that arise in testing.

As the development team begins work on the next sprint the testing team begins testing the changes from the previous sprint.

If defects are discovered they are added as sub-tasks under the Testing Support and Defect Fixes issue in the current sprint. These subtasks aren’t estimated individually and work begins on them immediately. Fixes are pushed back to the testing environment as soon as they are completed.

Questions and requests for clarification often arise during testing. We’ve found that adding them as comments to the Testing Support and Defect Fixes issue is a good solution. Developers will answer with another comment as they see them, often within an hour or so. This minimizes interruptions for our developers. The answers are also documented with the question and all of it is contained within this one single issue. If the answer prompts a defect to be entered then that’s easy to do since the tester or developer is already viewing the issue.

Pros

The estimate is an indicator of the team’s confidence in the code that is in testing.
The estimate blocks out time in the sprint for the team to deal with defects that arise in testing.
The issue provides a channel for questions regarding testing so that questions are answered very quickly.
The issue groups defects together at the top of the sprint board so that defects are remedied very quickly.
The issue helps provide a complete picture of the work in progress.

Cons

Defects which are really feature requests can flow into the current sprint without being prioritized or approved. This requires discipline on the part of the development team to redirect these to the backlog.
The Testing Support and Defect Fixes issue may remain open until the end of the sprint. This can affect reporting, especially burndown charts.

Our Results

The first sprint after implementing this process was a huge success for our team and our company. We made a critical change to our subscription model that directly affected many of our customers. Several defects were found and fixed during testing. The changes were then approved for release to our customers. The development team also was able to successfully meet the goal of the in-progress sprint.

Implementing Our Solution

If you’d like to try this solution out for your Scrum team you’ll need an issue tracking system that supports ranking issues, sprints, sub-tasks, and comments. We use JIRA from Atlassian.

Additionally, we assign one developer to monitor the Testing Support and Defect Fixes to be responsible for making sure questions are answered and defects are fixed by the appropriate member of the development team. From the testing team, we also have a liaison assigned who is responsible for implementing the testing plan and communication.