A short consideration about the bugs in Agile (for Scrum teams): A team works together on a user story. And the definition of that being done includes that all development work is done and that all the issues or problems have been fixed before ending the sprint. However sometimes a user story can be interpreted in different ways. Or sometimes teams procrastinate in fixing bugs and bring in new work. They falsely consider the earlier work done. But there’s a big beast under water…
Situation: the product as shown is not good for the Product Owner
1. The user story was not clear enough for the developer: The developer thinks he understands the story but the BA has a different idea about the same.
Solution: create a new story, add it to the backlog and prioritize it so that it comes in the next sprint (or in the same sprint in exceptional cases). The story should have its own title, description, acceptance criteria and should also be demoed – like all the stories.
2. The story is clear but a mistake is made and not seen by the developer or one of the peer developers (peer review is important).
Solution: Two options, create a bug and add it to top of the product backlog, raise it during the call, find a developer who is available to volunteer and implement the fix. Take it offline in a separate call. Or create a new user story instead. Which comes across nicer. It’s a fine line sometimes between: “YOU MESSED UP, I NEED A FIX NOW!” and “no worries mate, you can fix that later… whenever yeah”
3. The developer made the right code but broke another set of code
Solution: Make sure that continuously, in every sprint, a part of the bandwidth of work is allocated to regression testing. Developers checking whether the existing software, that was made earlier still functions. Make sure that you have this in place if you do not want to end up in a jungle of something called technical debt.
Some teams bulk up so many bugs, while they continue to produce new software. In all cases, me and my peers advise to stop pulling new work but fix the issues at hand first. This might sound simple, but if you have the drive of a deadline coming close it could feel like you should try and create more software first. Which means: you are on a death march.