Scrum and Supporting Your Existing Products

Monday, September 29, 2008 – 4:07 AM

Click to find out more about bugs and beetles.Bugs! How do you handle fixing bugs and enhancement requests on an existing release of your product while your team(s) are working on the next release? Typically as you start work on a new version of your product there will be bugs or enhancement requests coming in from users of the previous versions. Successful software teams are able to address both the needs of their customers using the current release and implement features for the next release to address future customer scenarios.

It’s important to note that this is different from fixing bugs on your existing work. Scrum teams usually fix bugs on the stories they are currently working on as part of being “done” within a sprint. Bugs found after the iteration are simply added to the product backlog and prioritized accordingly.

In the case of new product development and released product bugs things are a little less clear. How do you balance these two activities? There are really two options here. And having tried both of them I can say that they each have pros and cons.

Separate sustained engineering and next version teams

One could opt to create a sustained engineering (SE) team who work with existing customers to fix bugs and add enhancements to the existing product. The SE team would also push requests for similar work, be it bugs or features, into the next release by talking to the new product development team(s).


  • New feature work is more predictable because teams doing new work are not impacted by varying incoming bug rates.
  • Teams don’t have to switch between different code bases and streams of thought as they’re not moving between different product versions. The can stay focused, which is one of the key goals of Scrum.


  • Moral. Nobody wants to work on the SE team when there are exciting new features to write. Assigning engineers who previously worked on new features to an SE team isn’t likely to be viewed as a promotion.
  • The team(s) developing new features don’t see things that customers are struggling with and feel their pain. They’re are shielded from the impact of code they wrote in the previous product.

Product bugs as tax across all teams

The other approach would be to treat bugs as tax across all the teams working on new product features. Each team works on the new product development and in parallel deals with fixing bugs in the released code base.


  • The team sees things that customers are struggling with and feels their pain. They’re not shielded from the impact of code they wrote in the previous product.
  • Team members will increase their overall knowledge of the product by fixing problems that might be outside the areas they are working on in the new release. Over time this will reduce silos where knowledge about particular functionality and code is concentrated in one or two individuals on the team.


  • Fluctuating incoming bug rates can make velocity very hard to predict. Depending on the length of your sprint and the required turnaround time on bugs you may be able to plan for and fix bugs in a subsequent sprint rather than attempting to fix them in the current sprint. Over time the team can use averages to estimate the amount of time they’ll need to meet their commitments to supporting previous versions.
  • Team members have to switch between products when working on new features and fixing bugs in previous releases.

Which is better?

Obviously it depends on your exact situation but I’d always choose to spread bugs across all the teams over creating an SE team. If at all possible I’d try and add these to the backlog, prioritize them accordingly and give teams time to plan to fix them in the next sprint. This is less painful that dumping them on the team to be fixed immediately. Sometimes this is unavoidable, if for example you’ve committed to a particular service level agreement around fixing bugs.

The initial pain of doing this may be large but over time the bug tax will become predictable and teams will learnt to plan for it. In the long term there are other benefits as your feature teams will have a better understanding of customer pain points and better overall knowledge of the product code (a reduction in silos).

Another alternative, which just occurred to me but I’ve not seen tried. This would be to have each feature team run periodic SE sprints. Every N’th sprint would be devoted to SE work. This theoretically has some advantages over the two approaches especially if the SE sprints were staggered across teams so there was always at least one team working on SE. I’ve not tried this. If you have I’d like to hear from you.

Next read: Managing Bugs with Scrum – Dealing with bugs on a single product.

  1. 8 Responses to “Scrum and Supporting Your Existing Products”

  2. It is nice to see other people having the same ‘problems’ we have. Scrum books/articles always talk about the simple case of only developing on one product version at a time, but in reality we constantly have 2 or 3 versions in maintenance and 1 or 2 new feature branches.

    We use the second method. I think it is important that developers feel the customer problems to improve their work in future (new feature) releases + Letting another team of developers cleanup the bugs/code of the new feature team, isn’t really a good motivator.

    Thanks for the article.

    By Dieter on Sep 29, 2008

  3. In your scenario 2, if you count “bugs” simply as something you add to your product backlog to be prioritized against everything else (and as a result you then don’t split your backlog between vNow and vNext), doesn’t velocity just work itself out? Additionally, you can be sure you are working the most important thing for your customer at the precise moment, whether that be maintenance of an old system, or creation of a new one.

    We do this in the Online Services space where we have more of an ongoing product life (rather than big boxed shipments), but it works great.

    By Paul Hammond on Sep 30, 2008

  4. One way to handle this is to allocate a person on the team to deal with production bugs. InfoQ did a great summary of this idea: We have adopted the “Ronin” moniker to give it some level of prestige. The Ronin is rotated on a weekly basis. We also provide stretch tasks that involve researching new technologies for quiet periods.

    By Gavin Terrill on Sep 30, 2008

  5. Paul,

    Yes. In the “Product bugs as tax across all teams” model the velocity will work itself out provided you don’t have an SLA that requires you to fix bugs within the current sprint. In this case planning sprints is a lot harder because you don’t know the amount of SE work going into the sprint.


    By Ade Miller on Sep 30, 2008

  6. Thanks Ade, very timely, practical and right on.


    By Jezz Santos on Sep 30, 2008

  7. The SLA consideration is a tough one – I am not sure you could do this reliably without a dedicted sustained engineering team. The unplanned work would be almost too impossible to predict, surely?

    Also, what if a bug is found that simply cannot be fixed in the current sprint timescale, within the SLA? I guess that would be where you cash in some of your customer goodwill you’ve built up with previous predictable shipping of great software… :-)

    By Paul Hammond on Oct 2, 2008

  8. Other than must fix bugs, focus should be on value creating activities.

    Fragmented focus is really just waste – most software has minor “issues”, and if they are in the nuisance category, and your strategic focus isn’t customer experience based, then you are not creating business value by fixing them.

    Can spend a lot of time fixing nuisance stuff, and it comes at a significant cost.

    By Hui on Apr 19, 2010

  1. 1 Trackback(s)

  2. Jul 21, 2009: Managing Bugs with Scrum | #2782 - Thinking about agile (small 'a') software development, patterns and practices for building Microsoft .NET applications.

Sorry, comments for this entry are closed at this time.