Maintenance victims – Handling maintenance the Agile way

Bugs used to be something very distracting and unpleasant for the software developers. For management they can be even worth – the effort and time bugs need to be fixed is poorly estimatable. Sometimes these number are complete question marks. This predictability drop is one of the reasons why agile methods advocate striving for bug-free development as possible

Scrum teams don’t like bugs just as any other teams. There are multiple approaches to handle bugs from entering into the product backlog and making them wait until the end of the sprint to allocating some “maintenance slots” in the sprint to a more-or-less expected amount of maintenance. The sad truth is in that amount of bugs discovered and amount of time needed to fix them is often not predictable even roughly. Especially for teams that are not yet used to deliver the tested features.

Maintenance victim

One approach that some teams find useful is to allocate a maintenance sub-team or a single maintenance person also known as a maintenance victim. This role is typically rotating every sprint and is usually taken on a voluntary basis. When such a team exists, bugs usually don’t clutter the product backlog and are maintained in a separate list. During sprint a maintenance sub-team is responsible for doing all the bug fixing so that it wouldn’t distract the other team members and would allow them to concentrate on creating new features. The maintenance people are not isolated. They still come to the daily standups, tell about their impediments and can get help from the other team members. At times of unusually high error rates the maintenance team can grow up to the whole Scrum team size.

Pros and Cons


  • Team does not get distracted whenever a new urgent bug comes in.
  • There is no or little conflict with the Product Owner or customers not wanting to wait until the end of the sprint for fixing that critical issue.
  • Most of the team members periodically get chance to experience the full maintenance pain. It helps them to understand what is difficult to maintain in the code and refresh the maintainability coding guidelines.
  • Some teams like the variety provided by the possibility for doing maintenance “sometimes”. See also the summary below.


  • For the teams of the highly specialized individuals it might be so that most of the bugs have to be fixed by a concrete person. If this person is not on the maintenance team this time, it might be difficult to cope with the issue even if this person does provide some help.
  • Since bugs are handled out of the sprint, possibly even out of the product backlog without the estimations, it might be not too easy to see how much effort is actually going to the bug fixing.


I know several teams, where people originally didn’t like this practice, but then started lining up to the maintenance role. The reason is that in their situation maintenance started looking as a way to sometimes take a rest from the routine of sprint cycles.

Did you ever try such an approach? Can it work for your team? Are there any arguments missing?

Photo courtesy of Ange Soleli @ Flickr

4 thoughts on “Maintenance victims – Handling maintenance the Agile way”

  1. Hi ,
    In my company we are goind to adopt scrum soon and the management has decided to create separate maintenance teams and a few feature teams that will develop new features. In order to enable this there is the suggestion to create a separate private branch in CVS for the feature teams in order to work without interuption. However the problem is when the code fixes done by the maintenace guys are going to be intergrated with the features. Who is going to do that? the maintenance teams or the feature teams? If that happens too often it will disrupt feature teams anyway.What is your suggestion to overcome such situation?

  2. I afraid there isn’t a singe correct answer, Max. It depends much on the details of your context. There are many adoption strategies that work for different companies.

    In general it is a good idea for teams to maintain the code they write – that provides motivation to create high quality code and raise the quality bar (and level of automation) over time. However, if you are at the moment overloaded with amount of bugs it might be a good idea to temporarily create a maintenance team to free hands of the others while they get started with agile and testing automation.

    Another general recommendation is to strive for a single code line except for release branches that ideally are created just before the release. Otherwise as you correctly note there is quite hight probability of merging-related problems. However, there also can be exceptions for the period of transition to Agile. For example, if the high quality standards and automated enforcements of these standards are not common enough in your organization and you already have branches, you might need to keep branching for a while and get rid of branches one by one while raising the level of automation, adopting test-driven development, etc.

    As a final note it might be a good idea to contact a coach in your region or visit some local agile meeting. Any advices depend very much on many details. For example, it might be useless and even harmful to all the code to be fully test-driven from the day one of the adoption if a team never did anything like that.

  3. Hi Artem,

    I have used this approach with several teams. I tend to prefer the alternative approach of treating bugs as stories that need to be prioritized alongside feature requests.

    One of the reasons I like the alternative approach is the risk of the bug database becoming a Virtual Product Backlog. By this, I mean that QA and others not directly responsible for prioritizing the Product Backlog may learn that they can circumvent the Product Backlog by entering a feature request as a high priority bug. This is usually not intentional deception. It is just too damn easy to do. And, frankly, there is sometimes a fine line between a feature request and bug report.

    Even if the bug database doesn’t become a Virtual Product Backlog, the team still has two competing masters–the bug database and the Product Backlog.

    The Eclipse Foundation takes another interesting approach. Everything is managed via Bugzilla!

    Good luck!
    –Kevin (

Leave a Reply

Your email address will not be published. Required fields are marked *