0

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?

Community
  • 1
  • 1
Viktor Livakivskyi
  • 3,178
  • 1
  • 21
  • 33
  • Where I work, manager yells and bugs get fixed, Scrum or no Scrum. Yes I know it's not an answer :-) But keep in mind too much rigidity can be a bad thing too. – Tobia Mar 14 '13 at 00:26
  • @phs, yes - it is not about programming language or algorithm, but it definitely related to programming. FAQ says, that I can ask questions about "software tools commonly used by programmers", which Jira and Greenhopper are. Moreover, links in my question lead to similar questions by their nature. – Viktor Livakivskyi Mar 14 '13 at 09:46

1 Answers1

2

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?

Rick Tonoli
  • 306
  • 3
  • 7
  • Another side note: make sure you have good practices in place that prevent lots of bugs appearing, like continuous integration (with continuous testing of course), peer reviews, unit testing etc. Something that also helped us was to integrate early and often, and introduce our testers to the features early in the sprint, even before it was complete, to eliminating potential bugs we would only have picked up later, when the story WAS complete. The key here, collaborate collaborate collaborate :) – Rick Tonoli Mar 14 '13 at 03:23
  • Thank you for sharing your experience! That is exactly, what I wanted to implement, but thought, that Greenhopper wants me to put bugs into backlog and fix them at next sprints, instead of current sprint. – Viktor Livakivskyi Mar 14 '13 at 10:00