For all software development teams, defects can cause a challenge on when and how to handle them.? In agile, with a focus on quality code, and user stories, sometimes team can be confused on the actual mechanics of how to address defects.? It is not a hard process, but the team needs to be clear on how they handle defects.? Let?s start by defining what we mean by defects.

What is a Defect?

For purposes of this article, we will use the term defects instead of bugs.? In many teams, there is sometimes confusion on when and where to identify defects?? If the team agrees on a standard process, this makes the mechanics easy.? To help teams identify how they might handle this, below are examples on good ways to handle this.? These are not cookie cutter solutions, but starting points that allow your team to try and refine these techniques.

[login]

Scrum Teams

In a standard scrum team, the team will commit to completing let?s say 25 points, which translates, let?s say to 6 stories.? While working on these stories, someone will test the story before it can get to done.? Sometimes that is a QA person, or in a more generalized team, hopefully a different developer will test the story.

If that tester finds a problem with that story, this should not be considered a bug or defect.? Sometimes teams will label this as such.? Labeling this issues as defects before the sprint for that story is done, is confusing to the product manager.? Because the story is not done, this cannot be a defect, the team has not said that we are ready for someone to use this.? The team acknowledges that this might not be finished, that is why there is testing!

However, any time after a sprint is done, if a defect or bug is found in that story, it should be considered a defect.? And how does the team handle this?

Kanban Teams

If you are using a Kanban board, and a defect is found after release (assuming release is your definition of done), that is the time to describe it as such.?? Identify the defect, create a task or story for the defect and place this in your backlog.?

Keep in mind that since many Kanban teams deal with Service Level Agreements (SLA?s), with their business owners, defects will need to be considered part of that.? For those SLA?s it is helpful to identify the defect at least as critical or non-critical.? Look to other material to help with those kinds of risk class service levels, such as those by David J. Anderson[1].? Now the team needs to handle this.

Give your defects visibility to Product Managers

First, teams must have business representation to help them make priority decisions.? The most common way to do this, is to designate someone as a Product Manager.? This could be a team member who communicates regularly with business stakeholders.? Ideally, this is a business person, who works directly with the team.

Once a defect has been spotted (defect according to our criteria above) the team needs to make that visible.? In the case of a Scrum team, this means logging this in your product backlog, as you would a story.?? For a team using Kanban, they would get that defect into their parking lot.? This also means, the team gives business the opportunity to prioritize the defect work.

The exception is for critical production defects.? This is covered in a section below.? For all other defects, once they are in some type of backlog, then the team needs to plan when to handle these defects.?

One question that might come up is should we estimate the effort for these defects.? Opinions differ [2], but to give business an idea on effort for those defects, it makes sense to size them in some way.? If your team is used to story points, then utilize that method.?

For teams using Scrum, tasking could be used.? In other words, when the team is in planning session, they will create the task time estimate for a defect.? For the dev tasks, they may estimate, 10 hours, for testing time, 4 hours, and now the team has an estimate that can be used with the teams total time budget to help identify if their sprint commitment is reasonable.

If the team is using Kanban, point estimating makes sense.? That way the product owner can identify the risk of not doing the defect until later, as opposed to getting a new feature out.? Many defects found really are more annoying and not critical defects.? So a savvy product owner can identify which issues can harm the product without being fixed, as opposed to when a new feature is needed.?

For Kanban, once the priority of the defect has been identified, then that token or story is placed on the appropriate place for that board.? In both the Scrum and Kanban scenarios it is important to differentiate defects from stories.? The reason to do this is to track defects, to make sure your quality process is on track.

For instance, see Example 1:

?Example 1 (Sample burndown chart tracking defects)

Looking at this chart, our burndown shows that the team is working well through their commitments, and buring down well.?? However, the defects showing at the bottom show a disturbing tendency to go up more as we get through the project.? Maybe this is expected from the team, but it would be great topic for a retrospective.? Tracking how the team is doing with their defect rate has to help drive improvement.

Production Stopped Defects

The exception to the above is any defect that is affecting production.?? In this case the team needs to have rules on how to handle this before it happens.? Make sure your team is prepared to handle these inevitability.?

Certainly, if a critical production defect is found, the entire team can swarm on this defect to get the fix done, and pushed out to production.? The advantages to this include a quick turnaround time.? Also, the developers who originally worked on this piece of code would be involved.? Although assuming the team uses Pair Programming, this would not be an issue.? Disadvantages include the possibility of a Scrum team blowing their commitment to the sprint.?? For a Kanban team, this might cause them to blow their SLA to the customer.?

These are the risks and advantages to using a swarm strategy.? Another consideration here is how many critical defects on average does the team produce within a given time period.? One would hope that this would be a rare exception, but sometimes that is not the case.? Consider this aspect before deciding on a swarming strategy, and back it up with hard data.

Another way to handle these issues would be to designate a team member for a short length of time as your on call person.? It has been called the batman position, the position no one wants and more.? The idea is that this member of the team would not be counted on to contribute significantly to new project work for that period of time.? They would have to triage the production issues to determine if they are critical and need to be fixed, or could they be put in the backlog.

It would also make sense for this position, during slack time, either works on prioritized work, maybe helping with testing, or make this learning time.? Allow this person to investigate a new technology the team wants to use.? Besides helping the team, this makes this position a little more attractive to team members.? Usually this task is not one team members look forward to performing.

This method helps keep your new production work more predictable, and allows the team to focus on completing the work committed to.?

Handling Defects in an Agile way

These strategies for attacking defects are not necessarily agile in nature.? However they do work well in agile teams.? The real trick is to make sure that the team decides on which method to use, this should not be decreed from management.? Management can certainly demand that the team documents to them how they handle defects though.? That seems reasonable.?

Using some preplanned method for handling defects helps teams with a smooth delivery, and keeps them out of a reactionary mode.? Make sure that your team has a plan!