Dealing with bugs in Scrum via GreenHopper [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

We're re-organizing workflow in our team and one of the key decisions was to use Scrum process, provided with help of Jira and Greenhopper.

I've read various Scrum guides, documentation of Greenhopper and started Scrum process implementation in our team. After some corrections and changes it mostly good, but one thing doesn't let me sleep well: bugs.

Different solutions are proposed by developers, but I still can't find my way here.

In our workflow any issue lives in 4 states: Open -> In Testing -> Resolved -> Closed

When developer is satisfied with his code he puts issue to In Testing state, and it becomes automatically assigned to QA lead. QA verifies the issue and, if everything is ok issue becomes Resolved. If not - Open again. In Resolved state code review is performed, and if code is secure, optimal and fits the developed structure, issue becomes Closed. If developer did something wrong - Open again.

The tricky part here is re-opening of an issue (story), because at same time bugs are raised, which land in product backlog - not sprint backlog, and due to Scrum-way developer can't work on issues, that are not in sprint backlog, but at same time story can't be closed, because code is buggy or written bad.

So, the question is: should a story be closed, even if it has some bugs, related to it, and these bugs are planned to be fixed in further sprints?

Or story can't be closed, until all related bugs are fixed, meaning that if a sprint is finished, but not all bugs are fixed for a story, story remains opened, excluded from finished sprint and moved to a next sprint, so it's story points are not burned in finished sprint?

Answer 1

Having had a similar situation one of the key things we found was missing (or deficient) from our stories was a well defined (and agreed upon) "Definition of Done" (DoD). If you have well defined "done" criteria then when the story is complete (meets the DoD) then it's complete, of course the trick becomes how to define a good definition of done that's not too vague, ensures good quality, everyone agrees on and is actually doable. For me it's not a once of exercise either, we would continually re-look at it in each retrospective to make sure they were still relevant and made changes as needed. For ideas on setting up a good DoD try Google, there are a lot of good exercises teams can do to define it (like this one).

As to when bugs that slip through get done I'd say they should be fed back in to the Product Backlog and be prioritized as per normal. Bugs that come up during the sprint related to sprint work should be fixed in the sprint (avoid admin / paperwork!). Remember also lots of bugs (or an increasing number of bugs) generally mean there's a problem with quality, maybe there's a bigger issue to deal with (too much pressure to finish perhaps?).

To summarize have a look at getting a solid DoD (that encourages quality over quantity) and continually improve it, slow down and do less better instead of more "with bugs" and when bugs DO appear, feed them back into the product backlog and engage the PO to prioritize it as soon as possible.

As a side note we found that when it came to dealing with lots of bugs, a more lean approach like Kanban worked far better than the 2 weekly iterative approach of our Scrum process.

Hope this helps?