19

What are some of the different patterns you use to schedule maintenance work (any non-feature work like bug fixes, technical debt reduction, etc.)? In our organization, we've considered mash-ups of the following:

  • Finish feature commitments and then peel off teams for maintenance work during test or warranty cycles
  • Bug Quash (a social event where the goal is to fix, or “quash”, as many bugs as is humanly possible in a time-boxed period)
  • Schedule fixed capacity up front in each release (e.g. plan for 1 sprint per team in a release)
  • Dedicated full-time bugmeister to triage and coordinate fixes with teams
  • Ping-pong the maintenance work between off-shore teams

Note, we follow two guiding principles in this area of practice:

  1. People should fix their own bugs to the extent possible
  2. No dedicated maintenance teams

Note, too, the reality is we have bugs. Please don't tell me to find a way to eliminate bugs so that we don't have to worry about solving for this problem. I'm interested in other ideas about how to approach the problem.

(P.S. credit Nate Beck for the Bug Quash idea - thanks Nate!)

Improve this question
1
  • 2
    +1 This is a great question, and one that our industry needs to think about a lot more. – Nick Hodges May 26 '11 at 15:18
9

One thing I don't see in your question is any information on your SLA. This is important as if you have SLA in place you may be forced to inverse priorities and agree that (at least some) bugs go first and new development goes second.

If this is the case another option is:

  • Finish commitments regarding bugs and then invest rest of the time into new development.

Minor bug which has 60-day long resolution time becomes important after 58 days. Also if you don't have enforced SLA you can agree internally for informal SLA for specific bugs so you create the sense of urgency and important bugs eventually get fixed.

Another approach you can use:

  • Put bugs along with new features in a single backlog and allow the team and PO prioritize work items against each other.

This way you make conscious tradeoffs when you decide what to do. Also it's a good thing to visualize the difference, e.g. with different color of sticky notes so PO sees how many bugs you have when they want to push new things into development. After all, if the product is buggy, no matter how cool it is, people won't like it much.

I would also:

  • Challenge your rules regarding bug-fixing.

I don't say they're wrong but I found in a couple of teams that skipping the rule that "everyone fixes their own code" brought us closer to collective code ownership and improved the pace we were learning each others' code.

Improve this answer
1
  • 2
    +1 for the comments around managing to internally agreed-upon SLAs and "last responsible moment" concept. Those can become a factor in prioritization, too. – Sean Rich May 23 '11 at 13:22
3

I've seen projects in which almost all of the methods you mentioned above were being used. This is a comprehensive set of methods to handle maintenance work in SCRUM.

Usually the PO is more interested to push new features development to the sprints contents. The development team usually tries to reduce technical debt, to re-factor areas of the code, to develop maintenance items that would make it easier for them to further develop the code base in the future and more.

The best way I've found to work this "tension" between the PO and the development team is to agree on a capacity distribution between new features and maintenance (or non-functional items) on a release basis. Then, a good approach is to maintain 2 backlogs

  1. New features backlog - maintained by the PO
  2. Maintenance backlog - maintained by the SCRUM master and contains the maintenance items that are not functional.

You should note that when maintaining 2 backlogs, you will put the functional bugs (bugs that are related to features development) in the PO's backlog. These bugs need to be prioritized with the other items in that backlog.

The maintenance backlog will include items that are non-functional, infrastructural, re-factoring, tools development, etc.

Using this method would allow avoiding a lot of conflicts with the PO around what's more important - the re-factoring of component X or new feature Y.

During the release planning (or every so many sprints, if the release is long), the PO and the team should agree on the capacity distribution by looking at what's in both backlogs and considering the priorities of the project as a whole.

Now, regarding functional bugs, bug quashes is a nice method, however I think an effective way is to allocate some of the team's capacity to bug fixing in each and every sprint. Ideally, you can plan for specific bugs you'd like to fix during sprint planning but sometimes you need to plan for the unknown (severe bugs that were not found yet). You'll want to allocate capacity for these.

Improve this answer
1
  • No the Scrum Master's role is not to maintain a backlog. – Stefdelec Jun 20 '18 at 6:09
1

Don't.

Your velocity dips because you are fixing bugs and paying off technical debt. That is a good thing. Your velocity is the measure of how much work your work system (culture) allows you to complete in an iteration. Let it be that measure.

Fix all the bugs that matter. Clean up all the technical debt you can as you work. Plan based on velocity. BTW: when you use "pure velocity" this way, then the question of "how to accelerate" is obvious, yes?

Improve this answer
1
  • 1
    Is the answer to the obvious question "ignore technical debt — we're only getting punished for working on it?" – mattdm Mar 7 '12 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.