How to manage Issues/Defects relating to the User Story being tested?
Following on from a previous post also titled “Issue/Defect Management” which asked a broader waterfall/agile question.
I’d like to just check the sanity of our current Agile process with a larger audience.
We operate a 2 week sprint cycle not cam-band. A User Story(US) moves across the sprint board from “In Progress” to “Team QA” (= code review) to “Ready For Test”.
During the test cycle if an issue with implementation directly related to the US is found. We will discuss the issue with the developer, then in the comments of the US will detail the issue seen and steps taken to replicate. Finally setting the US back to “In Progress”. Where the developer will continue to work on their US.
If we find a separate unrelated bug we will raise a bug which will be prioritised by the PO for backlog/current sprint.
In Jira we can track that a US has moved left on the board, from “Ready For Test”, rather than right.
So can capture metrics for issues found, if we need to.
We find this a much faster process than raising a separate US/Bug for every issue, which would then need to be prioritised by the PO and either brought into the sprint or put on the backlog (which would then block the current US in this sprint).
We also feel it follows a similar model to other US QA steps, such as Unit Test or Code Review.
Where I’m sure no one would raise a bug for a code review issue, or a unit test failure?
As with processes in general, whatever works best for you is the best and it sounds like you have thought about your process. I have been working in teams that have had a similar approach. And in those we have had all of these hand overs between code → code review → test → release → done and in most cases we found all that moving around things to provide a status of a task more administration than it was worth. A concept that I like that we implemented more often than not was the “Definition of xxxx” pattern.
Basically a checklist to see if you can move a user story. The two main ones are Definition of Ready (what needs to be done before the team can start to work on the story) and Definition of Done (what need to be done before the story is ready). The latter has also more often than not been a cause of a lot of learning. These definitions is a Checklist. i.e. Unit Tests updated, Code Review Performed, All outstanding Bugs reported and so on. So instead of having a lot of columns on the board you have the status in the story as the DoR.
Regarding the reporting bugs or not. I personally like to report as few bugs as possible but that works best when the time between developer implementing a thing and a tester testing it needs to be short. I would aim for 1 hour. When your feed back loop is counted in days or weeks you need to report them because you will have a few occasions where you find a thing and the developers will not have the time to fix it in the sprint. Thus it needs to tracked to not get lost. It sounds like you have a sweet spot there where you report the non story related bugs and work with the related ones as comments.