Skip to content

Maintenance victims - Handling maintenance the Agile way

  • strict warning: Non-static method view::load() should not be called statically in /home/artemmarchenko/ on line 823.
  • strict warning: Declaration of views_plugin_display::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 1684.
  • strict warning: Declaration of views_plugin_display_page::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 457.
  • strict warning: Declaration of views_plugin_display_block::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 184.
  • strict warning: Declaration of views_handler_field_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 243.
  • strict warning: Declaration of views_handler_sort_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 82.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 608.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 61.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 61.

May 2, 2008 by Artem Marchenko

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

About the Author: As the Editor-in-Chief for, Artem is charged with overseeing the direction for content, advertising, and the overall management of the site. Nowadays in his day life, Artem is a product manager in a global telecommunication company where he leads the development of a product developed in extremely distributed environment. Artem has been applying Agile and researching Agile since 2005. Contact Artem


Branching is usually good, when minimal

June 5, 2008 by Artem, 7 years 25 weeks ago
Comment id: 1567

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.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of