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.

  • Good question, but I would expand it to also ask what about the process works well and what doesn't... What would they change?
    – Walter
    Dec 24, 2010 at 16:33
  • Who is reporting these bugs - developers or QA? When do you release code to QA - at the end of a sprint, or during it? If the latter answer to both questions, then you'll predominantly get bugs related to stories that were done in the previous sprint, i think, and if not, not. Which distribution you have might colour your bug process. Dec 27, 2010 at 14:21

5 Answers 5


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.

  • 2
    How do you track that the bug exists? Let's say that person A finds the bug and person B fixes the bug. Don't you put something up on the task board?
    – user11347
    Dec 26, 2010 at 16:43

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.

  • "a bug is just a story that already has a failing test" - that's great!
    – ianmayo
    Aug 30, 2018 at 7:24

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.