How agile teams handle maintenance work

Posted on July 7th, 2010 in Agile, Lean by siddharta || 2 Comments

Agile teams that make releases to production every few weeks are likely to have a substantial portion of project with new product development on upcoming stories running in parallel with maintenance stories from previous releases. This is unlike traditional processes where maintenance only starts at the end of product development.

Therefore it is all the more important for agile teams to be able to effectively manage both new product and maintenance together. This set of slides shows different ways to do that:

1. Have a single backlog

This technique involves having a single backlog containing both new feature stories as well as bugs and support stories. The whole list is prioritized and the team works from the top of the list. To do this effectively the product owner needs to have the knowledge to decide on the tradeoffs involved in prioritizing the list. For instance, the PO should be able to understand whether a refactoring is important or not, whether a bug is critical or not.

2. Have multiple prioritized lists

Usually the PO only understands the the new feature perspective and may not be able to effectively decide where a particular bug or refactoring should be prioritized with respect to new features. In this case it is better to have multiple prioritized lists, each list maintained by a person who understands that perspective. The bug list may be maintained by the test lead who understands which bugs are most important to be fixed. The refactoring list may be maintained by a dev lead and so on.  All these people would be a part of a product owner team.

Each list is prioritized by the person who maintains the list. At the time of sprint planning (or if you are doing kanban, then when starting to pull to the backlog) the maintainers of each list get together and discuss the top few items from each list, which are then combined into a small backlog to support one or two upcoming sprints.

3a. Allocate capacity by time

In this method you maintain independent lists and divide up the capacity to handle each one. For example, the team may decide to spend one day a week on bugfixes, one day on technical stories and three days on new features. This method is fairly simple, but also suffers from the problem that you may end up doing low priority new feature at the expense on a high priority bug fix and vice versa.

3b. Allocate capacity by sprint

An alternate method of the same technique is to allocate capacity by iteration. For example, two iterations of new feature development followed by one “hardening iteration” of only bug fixes. This is generally a method to be avoided for a couple of reasons. The first is that is delays even critical bugs. The second is that it compromises the ability to keep the software ‘potentially releasable’. Finally it can lead to a waterfall mindset where you do a certain amount of feature development followed by bug fixes.

4. Always fix bugs first

This strategy is popular with zero-defect teams. The problem with this is that you may end up fixing a number of low priority bugs when you could instead be working on an important new feature.

5. Have a separate team

The worst solution of the lot for the reasons mentioned in the previous post, but perhaps the easiest for an organization that is not used to combining new development and maintenance. Simply maintain separate teams to handle each type of story.

Comparision between the techniques

A single prioritized backlog is the best solution with a knowledgeable PO who understands all aspects of the project. Otherwise multiple prioritized lists are a good option.

What do you think? Are there any other techniques that you use? Do post in the comments below.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

2 Responses to “How agile teams handle maintenance work”

  1. the scrum mistress Says:

    we have two streams: Bugs/Hot Fixes and Product development.

    If something is broken then it needs to be fixed right away. A hot fix is a change or product update request but because the environment we support cannot wait for the next release it must be done immediately.

    Product development is on going. Sometimes hot fixes are deemed to simply be product development. The PO makes that decision and he is the product’s inventor.

    This works well for our particular situation where we cannot maintain separate teams and the demands of the business are constantly changing.

  2. Alex Says:

    We currently institute a sustained engineering team to handle hotfixes and patches so scrum teams don’t get randomized and the customers can get hotfixes in just days instead of weeks or months. I agree that this is not the best solution. Primarily because the teams should be paying off their technical debt as well as having 100% understanding of the changes happening to their code base.

    Some of the pain points of having the scrum teams stop what their doing to fix incoming bugs are:
    – Stop your train of thought and shelve partially completed changes.
    – Switch out of their current branch and into the old one.
    – Get the old QA build deployments going again for verification.
    – Break current sprint commitments and reduce velocity.
    – Deal with the “do we implement a temporary hack or refactor” problem that tends to come up with customer issues.
    – Write documentation and get it over to ops and release management.

    All of the issues aren’t blocking us from going in that direction but we have some work to do before can connect all the dots so teams can easily handle this work flow.

    I think we are heading toward the preferred model where teams will drop everything to fix
    bad bugs and they will rightly take a hit in their velocity to pay off their technical debt.

    I certainly appreciate you sharing your thoughts with us. We’ve been sharing some your articles with other folks across the business.

Leave a Reply