What is the bug workflow on your agile/Scrum team?
Here is ours: - If the bug is related to a story in the current sprint, we fix it. - If the bug is not related to a story in the current sprint and it is not critical, it is sent to the product owner for prioritization. - If the bug is not related to a story in the sprint and it is critical, we fix it.
Anything related to work in the current sprint is fixed, we don't even consider them bugs and do not write them up as such. We only consider something a bug if it is part of something we already considered Done.
When a new bug arises, we add it to the backlog and it get prioritized by our stakeholders. If we have time remaining in a sprint, we tend to tackle easier bugs that may have lower priority but are something we can complete in the time remaining.
I always thought a bug is just a story that already has a failing test, thus it's better defined than the typical first draft of stories for features.
So if you are convinced that bugs are stories, you treat them as you would other stories in regards to estimations and priorities.
I think the best way to approach this is to determine what you actually want to consider a Bug first.
A lot of developers will not consider something that isn't working as intended that they are currently working on as not a bug, because it is honestly not a bug. If you are currently working on something and it still has defects then the specific bug isn't actually complete so there isn't an actual defect. The inverse applies to completed work, if you have determined that something is complete and ready for testing/release/production and you later find a defect in the code or use then you definitely have a bug.
My company uses the following methodology to determine when a bug should be corrected:
If the bug is critical then it is added to the current sprint related to that product, at the appropriate priority. Typically we plan in approximately 10% extra time to allow for this into a sprint, as well as having the extra things that we don't actually plan on completing but if we have no bugs or something was completed faster than we expected we can then complete.
If a bug isn't critical then we simply add it to the backlog and normally complete it in the next sprint.
why this is the ideal flow there is some obvious leak to it, and sometimes things that aren't 'critical' from a programming perspective may need to be completed immediately if management decides that it needs to be completed earlier than we think it should be completed.
In an aside I think that the best thing to do is to pick a structure and then stick with it. Some of the biggest losses to productivity start occurring when you start doing things without structure. Once you start degrading your structure it is very easy for it to go all downhill.
That may have overly answered your question, but those are just my thoughts on how these things should be handled.
We do ongoing defect work. Similar to your setup, if there is a critical issue related to current work, we fix it as part of the work. After all, can't call a story "done" if there's a defect related to it.
For other bugs, we generally fix them as time allows. If there are pressing issues, we pull back some stories and spend time on bug fixes before getting back to normal feature work.
Bugs found during the Sprint are just part of the development.
Bugs found after the end of the Sprint go into the Product Backlog. We never argue with the users if something is a bug or an enhancement or a change. If the user wants to call it a bug, then fine, but it still goes into the PB just any other new work.
