Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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 '10 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. –  Tom Anderson Dec 27 '10 at 14:21
add comment

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.

share|improve this answer
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 '10 at 16:43
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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