-2

After being part of a project that tried desperately to run Scrum and failed miserably to uphold most of the principles, it has now fallen to me to manage this project and I am keen to avoid the mistakes that I have seen before.

I have a question around dealing with newly discovered defects. I know that the general feeling is that they are added to the current sprint or the next one and fixed quickly. Other throw them all in the backlog and get to them when they become more important.

That's fine, but consider the following situation: The current sprint is part of an epic and we are implementing new functions that are part of a larger requirement, and while we want to build and release for the customers to review, we would not yet want to release the features into product as they would be inadequate for use. What if we discover a critical bug, maybe by the customer, how to work that into the plan?

Options that I see them are:

Drop everything on the sprint and do an out-of-bands release + The customer gets their problem resolved quickly - Disrupts the current sprint and will probably cause it to fail - Requires another branch and merge operation

Work them into the current or next sprint + Maintains the order that Scrum brings us + No need to branch the VCS/Deal with problems in the merge - Customer has to wait longer to get their fix, especially as we are working on an epic and may be a while before we can RTC

Am I missing any other options? am I missing something about the process altogether?

CurlyPaul
  • 1,138
  • 1
  • 10
  • 29
  • Possible duplicate? http://stackoverflow.com/questions/1593328/best-ways-to-fit-bug-fixing-into-a-scrum-process?rq=1 – Nick Heppleston Feb 13 '15 at 17:26
  • I saw that question and considered many of the ideas discussed. I feel that this question is different in that it is asking specifically about feature breaking bugs while the current sprint is half way through an epic that may not pass as an acceptable RTC – CurlyPaul Feb 13 '15 at 17:37
  • 4
    I'm voting to close this question as off-topic because [project management is now off-topic on Stack Overflow](//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website-to-ask-about-project-management-issues/343841#343841). Ask these questions on [SoftwareEngineering.SE](//softwareengineering.stackexchange.com/) and [ProjectManagement.SE](//pm.stackexchange.com/) instead. (You can also flag for moderator intervention to have this question migrated.) – robinCTS Oct 28 '17 at 02:17

1 Answers1

2

There are two types of bugs that happen in Scrum. The first type is bugs that occur during development and are caught before being released. The second type is bugs that are discovered in the production environment.

Typically a Scrum team would handle these two types of bug differently.

Bugs that occur during development will usually get immediately fixed. Remember that the idea of Scrum is to have a releasable product at the end of each sprint. If you have outstanding bugs at the end of a sprint then you would not usually describe that as releasable. Also, when you delay fixing bugs the time it takes to fix the bug often increases. A developer fixing a bug on code they wrote the same day will usually fix it quickly. Ask them to fix a bug on code they worked on several weeks ago and it can take much longer.

With production bugs it is important to decide on the severity of the bug. For example, very severe production bugs might need to be worked on immediately and require an emergency release. When this happens you may well have to consider ending the current sprint and re-planning. With less severe bugs they should be added to the backlog and prioritised against existing work. For example, a Product Owner might decide to wait before fixing a bug because they believe it is minor and has little impact.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • It was the production bugs that I was aiming the question at. I'm coming to the same conclusion that real show stoppers would cause the sprint to be abandoned while they are dealt with. – CurlyPaul Feb 13 '15 at 17:41
  • Stopping a sprint isn't a disaster. It is better to re-plan than to carry on with additional unplanned work. What it does emphasise is how damaging production bugs are. That is one of the reasons that automated regression testing can be justified. Better to spend the time before the release than after it! – Barnaby Golden Feb 13 '15 at 19:47