Or as we call them, “defects”. Can creep in during any phase – as early as user stories, requirements, or during design and of course code. The best attempts at agile scrum, testing phases, pair programming, and other best practices and the bugs still creep in (no pardons for the pun).
So here is my issue – in a normal waterfall development cycle, there was a clear change management process – either resolve the bug during the long test/fix cycle, or schedule for a follow-on release – based on impact to customer and effort.
Now, how is this different in an agile environment?
First challenge: 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 where our work in progress is and who owns it at any time – think of it as our electronic Kanban board.
Second challenge: with short sprints, the likelihood of a bug not getting fixed increases. So what happens? Does it automatically flow onto the next Sprint backlog or does it go back to the beginning to be prioritized by the product owner?
Third challenge: Who decides the impact? Perhaps the best approach to that is to determine where the bug first initiated and put it back to that owner – whether the product owner or SCRUM team.
Fourth challenge: Which Sprint retrospective covers this issue – the one where it was uncovered or the one where it was resolved (assuming that more data on root cause is available in the latter)?
I would like to hear other thoughts. So much of the agile literature focuses on how to do agile by the book, and I am looking for insights on who to handle agile when things don’t go according to plan.