3

I would like to ask regarding our situation. I just joined a startup company and they are starting to do scrum (although I would say it was a poor implementation of scrum with no assigned Scrum Master nor Product Owner). There is a new project being developed (UI and database) and it relies on a big component (let's name it as Component X - the hardware abstraction layer and low-level hardware access) which was developed a long time ago. Component X was very big, heavily multi-threaded however, it doesnt have any unit tests (I'm quite surprised that nobody knows how to do unit tests in this company) and it does rely only on system unit tests performed by the testers/QA and there are some issues that weren't addressed ever since but the engineers who developed it are still addressing the bugs once it was caught by the testers.

Now, we started Sprint 1 and we are re-using the old Component X, the testers are just putting the crashes into our Agile Jira log and now, the Agile Jira log looks like a bug tracking with more items being put by the testers rather than the Sprint Backlog items.

It's good that Scrum was able to expose this as early as Sprint 1, but how do we address this kind of scenario? Should the testers log the bugs once they are found (our boss, directly told us to log the issues once they were found so that it could be backtracked easily through history search) ? I am thinking of using a dedicated bug tracker e.g. BugZilla so that our tester will never clutter the Backlog items on our Agile Jira. Although if we have a separate bug tracker, there may be instances that the feature is Done on the Agile Jira, while there is an issue logged on the separate bug tracker which could bring confusion to the developers and testers.

Improve this question

2 Answers 2

Reset to default
7

There are two kinds of bugs found during a sprint:

  • Bugs resulting from current, on-going development work
  • Bugs found during the sprint but from work that was done previously

The usual Scrum practice is to prioritise bugs found that were caused by on-going development work. These bugs will be added to the Sprint Backlog as they are blocking stories from being 'done'.

Bugs that existed before the sprint started, but that were discovered during the sprint (e.g. bugs found on Component X) should be added to the Product Backlog and not to the Sprint Backlog. Usually the Product Owner would then evaluate these bugs on the Product Backlog and decide how they should be prioritised.

This should keep your sprint backlog relatively clear. The Product Backlog will be large, but that should not be an issue as a team mainly needs to focus on the items at the top of the Product Backlog.

There may be a situation where a legacy bug stops the team developing a user story that they planned for a sprint. In this case the team and the Product Owner should discuss the bug and decide if it is realistic to fix it in the current sprint. They may instead decide to move the user story out of the sprint so that it can be re-estimated now that there is a better understanding of what is involved in doing the work.

Improve this answer
2
  • 1
    Hi, your insights are very logical and reasonable. Thanks for sharing.
    – newbie programmerz
    Commented Sep 19, 2015 at 16:30
  • 2
    At my company we have a separate for production issues. Any bug that exists in the shipping product. This is separate even from the product backlog. During sprint planning, our scrum teams will take a percentage of their backlog from the production defect backlog (technical debt). RIght now we average about 20% of our sprint backlog for existing bugs and 80% for new development (including fixing bugs in the new features).
    – Joel Bancroft-Connors
    Commented Sep 19, 2015 at 17:06
1

I'd let the testers continue to log the bugs, but have them logged to the backlog where the bug seems to be a pre existing issue. By default I think these should go to the bottom of the backlog (that's how Jira worked last time I used it). Whoever is acting as the PO can then process these periodically and prioritise them into the relevant place on the backlog.

I'd suggest against having a separate place to log these issues. What happens if one is in the wrong place and needs to be moved? (manual work to do so) or when you want to put them on the plan? Also, it feels like this may be 'hiding' them in an 'out of view out of mind' kind of a way. If there are critical quality issues with your product you need to know about them. Possibly having them weighing down Jira as a good way to do that, fixing that by hiding them from Jira is not going to benefit the business in the long run.

As you said, it's good Scrum has helped you identify this issue early on. Hopefully you can course correct now and get those bugs fixed before building more on top of shaky foundations.

Improve this answer
1
  • Hi, what you suggested makes sense. As of the moment im not implementing anything yet. I feel that i still need to weigh all the pros and cons of every solution. I will include your suggestions in our brainstorming. Thanks so much
    – newbie programmerz
    Commented Oct 1, 2015 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.