How to Handle Bugs Logged During a Sprint

skyscraper

During the agile development cycle, sprints are planned with clear cut items committed from the backlog.  How should defects that are found in code be handled?  Should they be added to the current sprint?  Carried over to the next?  Logged and prioritized later?   A lot depends on scope and team preference.   Often a team will define certain criteria that bugs should meet if they are going to be fixed in the current sprint. For example:

1.  Bugs should be less than 1 story point in size.

2.  Bugs should be related to work contained within the sprint.

3.  The overhead of bug fixes should not prevent currently committed work from being completed.

If bugs are quick to fix and the team wants to take on the work, it may be less overhead to simply fix the problem as part of the user story that is most related.   If bugs are found that are related to code not modified in the current sprint, if they are very large in scope, or if they would otherwise be distracting to the team, they should be logged.   Some teams log these defects as separate user stories, others may choose to use a separate problem tracking system (PTS) to capture defects.   Regardless, it is important as a development org and scrum team to work together to define a clear way to capture and handle problems and errors that arise as agile work is completed.

Comments are closed.