In a previous blog, I had talked about my issues (or should I call them challenges) with dealing with bugs found during a sprint. The first one I mentioned was
Does the bug get reported on the backlog or in a ticket or both? We still use a ticket management system to keep track of our work in progress – think of it as our electronic Kanban board.
I’d like to elaborate a bit on this one, really hoping for some good input.
So as mentioned, we keep both a ticketing system for WIP (work in progress) as well as SCRUM Backlogs – both product and sprint. For the most part, as bugs are uncovered during a sprint, a ticket is opened. The first and best result is that a team member picks up the ticket and resolves the problem during the sprint. That’s the easy one. What about when it can’t be handled in the current sprint. Does it go on the product backlog? Stay a ticket? Both?
Right now what we are doing is –
- If it started as a backlog item that is now failing, we add the issue to the backlog and it goes back to the start of the prioritization and scheduling process
- If it was uncovered during the sprint, perhaps during a regression test, but did not start on the backlog, it just stays a ticket and these tickets are added to upcoming sprints by the team
Not a solution I am that happy with – as I do not like not having a single product backlog list. But the downside of adding every bug found to the product backlog can be guessed – too long and confusing a backlog for prioritization.
Would love to try out some alternative ideas and report on the results.