Handling Bugs Using the Scrum Approach to Agile Software Development

Benjamin Ayangbola
4 min readJun 10, 2020

--

Photo by You X Ventures on Unsplash

Agile is about managing changes within and to a project such that progress is not halted for any reason. You’ve had your tasks all planned out under a sprint, but bugs unavoidably show up. You’ve got 8 working hours in a day, and every hour already has its tasks. How do you bring bug fixes into your sprint? Do you create another sprint for bug fixes or halt what you’re currently doing and attend to the bugs?

After a few research on bug handling practices that fit into the Scrum approach to Agile software development, I show you a few things to note about handling bugs.

What is a Bug?

A bug is a functionality that does not work as intended when juxtaposed with a user story in your sprint.

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective […] User stories are a few sentences in simple language that outline the desired outcome.

- Atlassian Agile Coach

Whenever an implementation in a piece of software has an outcome that differs from “the desired outcome” defined in user stories, there goes a bug.

How Should You Handle Bugs?

A good way to handle bugs is to list them out and classify based on priority. The Product Owner scans the bug report and assigns each bug a high or low priority. The decision is then made to either infuse fixing of the bugs into the current sprint (for high priority bugs) or move them to the next sprint (for low priority bugs).

I'll quote the recommendations of jpeacock in his response to this Stackoverflow question:

• If the bug is easy/quick to fix (one liner, etc), then just fix it.
• If the bug is not trivial, and not a blocker, then add it to the backlog.
• If the bug is a blocker then add a task (to the current sprint) to capture the work required to fix it, and start working on it. This requires that something else be moved (from the current sprint) to the backlog to account for the new hours because your total hours available hasn't changed.

“Your total hours available hasn’t changed". If you’re scruming, then every task (bug fixing and what have you) should be factored into a sprint.

Using GitLab to Manage Bug Fixes

I have come to like GitLab because of the many features that the platform provides to aid agile software development. These features can be explored to make the best of Agile, especially with regards to handling bugs. When bugs are discovered, it is recommended that the QA tester create them as issues on GitLab. Each of these issues should carry a “bug” label such that a Product Owner can login to GitLab to check all open issues having a bug label. These issues are then listed out in order of priority to be discussed with the Scrum team on what tasks (issues) should be moved to the next sprint to give room for fixing high priority bugs in the current sprint.

What If Bugs Interrupt Our Sprints Too Often?

Photo by Steven Lelham on Unsplash

While bugs may be unavoidable, they shouldn’t be so frequent and much that sprints will have to be interrupted often to give room for fixing high priority bugs. If this is ever the case, the developer’s expertise is questionable and his rating as regards quality of work may suffer.

However, we should draw the line between bugs and additions (new features). If during a sprint demo, stakeholders request for this and that, and it was NOT originally part of user stories, then they want a new feature. It should be treated as such.

Avoid Demo Within a Sprint

As I draw the curtain, it is noteworthy that a sprint demo is meant to take place after a sprint, never within a sprint. If you have worked in an environment where stakeholders can call for a demo at anytime, then you’ll understand how such demos cause disruptions. When stakeholders (which may include the CEO and other top management staff) want new features/additions to be treated with the urgency of high priority bugs at a demo coming within a sprint, there could be dents on the whole agile process. A demo within a sprint should be avoided at all cost.

How do you cater for bug fixes within a sprint in your organization? Kindly share your thoughts in the comment box. Thanks for reading 🤗

--

--

Benjamin Ayangbola
Benjamin Ayangbola

Written by Benjamin Ayangbola

Husband. Dad. Software Development Engineer.

No responses yet