Click the button to start reading
The Craft of Smart Planning: How to Handle Defects in Scrum
Have you ever planned a car trip? Sometimes when you finally get out on the road, everything works like clockwork: the highways are empty and the sun is shining the whole time.
However, on other occasions, all the hotels are booked, or you hit inclement weather that delays the trip for days.
Planning a project with agile is no different. Even in the best planned sprints, the deliverable deviates from what was anticipated. These defects need to be addressed in order to deliver a quality product.
Yet, fixing defects increases a project’s scope, making it very difficult to forecast the completion date.
There’s no cut and dry method for managing defects. However, the ceremonies and roles in the scrum framework provide methods for tracking them. Let’s look at some approaches for handling defects in scrum, as well as some of their pros and cons.
1. Fix Defects During the Sprint
The most straightforward way to fix a defect is to work on it right when it’s detected. This solves the problem straight away.
However, a good agile team produces work at a consistent pace, and fixing defects mid-way could pose a challenge to this principle.
A time-consuming defect impacts the outcome of the sprint. In a sprint where two user stories were planned, fixing a defect may mean only one is brought over the finish line.
This causes the team’s velocity to go down. (Velocity is measured in the total point value of stories a team completes during a sprint.) A velocity that see-saws, producing a lot of work in one sprint, and very little in the next, isn’t agile.
Routinely fixing defects as they’re discovered also skews the story point estimates, making it hard for teams to plan sprints going forward.
2. Add Defects to Product Backlog
Another approach to handling a defect is to add it to the product backlog as an individual story.
This “work is work is work” mindset gives a defect equal weight as any other user story. The defect is assigned points, and completing it adds to the team’s velocity.
This is a good approach, in that it gives the developers credit for the time spent working on the defect.
However, this also has a way of incentivizing defects. When developers receive gold stars for working on defects, they aren’t concerned about preventing them in the first place.
A second option, then, is to add the defect to the product backlog but not assign it any points. Although this is probably a superior approach, it can be disheartening to a team. Time spent working on a defect detracts from time it would spend on a user story. The team feels like it’s taking three steps forward then two steps backward.
As you can see, handling defects as they’re detected is a bit of a conundrum. It’s hard to both fix them and maintain a constant velocity.
Utilizing the planning and reflecting ceremonies in scrum helps to resolve these complexities. Let’s look at some of them.
3. Play Planning Poker
When a team notices a lot of defects showing up during a sprint, sometimes this means the stories are too complex, and need to be broken down.
Planning poker is a method for estimating the complexity of a story. Teams “play” this during sprint planning.
In this game, team members use cards with numbers on them to rate the complexity of individual stories. So as not to be influenced by other team members, the point values are assigned privately, then the teammates reveal their estimates at the same time.
A higher point value indicates more complexity, meaning a story would take longer to complete.
The point values are based on the rapidly increasing Fibonacci sequence (1, 1, 2, 3, 5, 8, 13, 21, 34, 55). An estimate of 55, for example, indicates a lot of uncertainty around a task. In this instance, the story should be broken down into simpler tasks so the team has a better understanding of the work entailed.
A point assignment of 3 or 5, however, indicates the work is fairly straightforward and predictable.
Making accurate story point estimates keeps velocity constant and enables a team to complete everything in its sprint backlog.
When a team becomes familiar with software work and puts some time into making these estimates, it’s able to assign point estimates that take potential defects into account.
4. Identify Patterns in Defects
In order to track and manage defects, it’s helpful for a team to categorize the types of defects it encounters.
One type of defect in software development is build defects, caused during the development process. Another are release defects, which are defects that have passed the user acceptance testing (UAT), and made it to market.
After a team has worked on several sprints together, it’s able to identify patterns in its defects and plan accordingly.
For example, high incidence of build defects indicates the team needs to focus on improving the development process. A pattern of release defects indicates a need to improve its UAT.
A sprint retrospective is the ideal time for a team to discuss any patterns it detects, and work to collaboratively improve its processes and systems.
5. Refine the Definition of Done
Each iteration, or sprint, in the agile cycle works toward creating increment to pass onto the end user. When a team pushes to create this increment, it may not go through sufficient testing, resulting in a sloppy product with many defects.
In order to manage defects, a team needs to create criteria for what it means for increment to be code complete. Usually, this entails more than just writing the code.
It may include identifying and clarifying technical debt in the product backlog, and implementing processes for testing and reviewing increment before its release.
A thorough “definition of done” sometimes entails having a “done checklist.”
6. Hold Sprint Retrospectives
The sprint retrospective is the ceremony most scrum teams skip. However, consistently practicing this ceremony helps a team handle defects.
A retrospective allows a team to address systemic issues and defects as they occur, and prevents a scenario where a team needs to dedicate an entire sprint to fixing all the defects in the previous weeks’ work.
Whenever a sprint produces defects, the team has plenty to discuss at the retrospective. It’s important for a leader to allow the team to run this discussion. The scrum master may guide a conversation, but he or she doesn’t direct it.
7. Elect a Good Product Owner
It’s essential for a team to have a product owner who knows what’s what.
One of the agile principles is about “maximizing the amount of work NOT done.” When a product manager grooms the product backlog, he or she is looking for the stories that are going to really move the needle for a project, not necessarily those tasks that keep the team busy.
By addressing any technical debt in the backlog, and selecting cleanup stories for the sprint, a product owner addresses defects as they arise.
Keeping the stories broken down into small, manageable amounts of work also helps to manage defects.
8. Run a Hardening Sprint
The goal for a scrum team is to deliver increment at the end of an iteration.
However, when a team hasn’t sufficiently dealt with defects during individual sprints, a hardening sprint is helpful for cleaning up messes and clearing up bottlenecks.
It’s good to be transparent in the product backlog as to the necessity of a hardening sprint by disclosing any technical debt. This lets the stakeholders understand what is going on.
The hardening sprint is generally used as a last resort.
When a team has a solid definition of what “done increment” looks like, stories are broken down with accurate estimates, and retrospectives are utilized, then a hardening sprint shouldn’t be necessary.
Handling defects has a lot to do with good planning and reflecting.
The scrum framework of working in iterations and then reflecting provides many opportunities to fix defects, and to resolve systemic issues that cause them.
Sprint planning and sprint retrospectives are central ceremonies for managing defects. Tracking the types of defects a team comes across is also key.
The good thing about agile is that you’re fixing defects as they arise. In this respect, it’s far superior to waterfall, which allows defects to pile up until the end of the project. At this point, when there’s literally thousands of defects, it’s impossible to address them all.
So even if your scrum team has to run a hardening sprint, or the velocity see-saws from time to time, it’s in a much better place than it would be using waterfall!
Managing defects is particularly challenging in a distributed agile team. Teamly’s sophisticated project management software offers a wealth of resources to keep remote teams agile. Come check us out today!