RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


How to Handle Defects in Agile Projects

Using a preplanned method for handling bugs helps teams with a smooth delivery and keeps them out of reactionary mode.

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.


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.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date