#2782

Scrum and Supporting Your Existing Products

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).

Pros

• 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.

Cons

• 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.

Pros

• 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.

Cons

• 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.