Skip to content

Fixing Bugs in Scrum

The following post is inspired by an email I sent to our teams recently due to some confusion about when to fix bugs in Scrum.

It generated 2 responses:

1) Complete support from some (senior developer, architect and CTO) and

2) Debate and disagreement from others (Product Owners)

I will leave it to you to decide what you think. Keen to hear comments from either side. Warning: no one has swayed me in the other direction yet!

The email below….

There seems to be confusion about whether bugs should be fixed in the sprint they are found, or in the next sprint after sprint planning. Some people think that you should only fix bugs related to the stories of the sprint in sprint, and the rest should be postponed for a later sprint. I disagree. Here are several reasons why…

  • Any bug represents something in the system that is broken. If it is not related to stories in the current sprint that means it’s related to stories from a previous sprint. Since in Scrum we work in priority order a bug on a previous story means a feature that is higher priority than anything in the current sprint is broken. Why would I prefer to have lower priority new functionality, if something more important is broken?
  • If I postpone fixing bugs so I can ‘finish’ more stories I am skewing the velocity. If the Product Owner is using this velocity to plan what can be achieved they will get an ugly surprise when in the next sprint they can’t get as much work done because there are a pile of bugs that now need to be fixed.
  • Context switching adds overheads. If someone finds a bug today it is less costly and takes less time for us to fix it immediately. If we wait till next sprint, someone has to write down exactly how to reproduce it. Then next sprint recreate it, so that it can be fixed. This is waste.

The ONLY time it is okay not to fix a bug in the current sprint is if the product owner agrees we can ship the release without this fix. In that case the bug should be closed as won’t fix, so that everyone knows that was the decision. If the Product Owner wants it fixed later they need to add it on the backlog as a story for the next release to get it fixed. It goes without saying that if they want it fixed in this release, then the best time to do it is now.

Advertisements
5 Comments Post a comment
  1. Hi Karen,

    Your post reminded me of a post I have published a long while ago: Scrum and Supporting Your Existing Products, although your post handles bugs during the project, and not after the project.

    I would like to republish your post on PM Hut, where many project managers will benefit from it. Please either email me or contact me through the “Contact us” form on the PM Hut website in case you’re OK with this.

    November 11, 2011
  2. Yes please go ahead and republish. My blog is published under Creative Commons.

    November 11, 2011
  3. haha the age old situation of bugs should be fixed always – and take none of the time away from the new project. I call it “vapour-time”.
    I can understand why dev, architect and CTO see value in this and PO’s feel otherwise.
    Most POs seem to be driven by velocity – and if the team is on a sprint and working on new features then the velocity needs to be a minimum of x otherwise the proposed release (think project plan *sigh*) will be wrong. Somehow its easier to explain to stakeholders that for 1 sprint the team will work on bugs and stabilise (or some other “sales” word) the code base. oh and just for the sake of transparency I too am guilty of this …

    I see how following the approach in the post will – over time – lead to a velocity which is stable, but most people think only in the short term – which is: Right now we have SO many bugs that if we try and fix them all we’ll NEVER get any new functionality done. Most people also refuse to simply close bug – instead wanting to believe that at some point there will be this magical time that allows for the team to work on all mundane bugs ever logged and make the system perfect.

    LOL – all of this is why I love software development and why it gets me to tear my hair out in frustration sometimes 🙂
    I think the “answer” to the above is that the greater scrum team (dev,tester, PO & SM) need to discuss and understand tradeoffs and explain them to the stakeholders together. They should also keep in mind to inspect & adapt and keep trying new things – perhaps to keep, perhaps to understand better why it doesn’t work for them now.

    November 11, 2011
  4. How do you think technical debt fits into this discussion?

    November 13, 2011

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: