God bless, I never had a lot of deal with maintenance. But I am curious, is it possible to customize Scrum for maintenance?

If yes, how to guarantee SLA (if developers have a fixed Sprints), for example? Or what Product owner should do? Gather bug reports or something else?

  • 1
    Maintenance is not project management.
    – MCW
    Nov 29, 2016 at 16:52

4 Answers 4


I would have a look at Scrumban, it combines best of both worlds Kanban and Scrum.

Kanban gives you a more just-in-time way of planning where you can tackle issues that are incoming as soon as possible. Combining this with the Scrum roles and meetings leads to something that feels very good for maintenance teams.

Product owners should develop the long-term vision and the short-term priority list, just like normal. But instead of set fixed date planning meetings. Do just-in-time planning sessions with the Product owner and make a top-list of items, repeat this when-ever the short-term backlog is nearly dried up.

There is one good question, when to release? Release when ever the work you need to release is finished or release everything that is finished on a set date. Focus on getting stuff really done and make sure you have a branch that is always in a releasable state.

Also read the free e-book: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf

Maybe also check this question, where possible ways of handling adhoc work during a sprint are explained.



While it may be possible to use Scrum, queue-based frameworks are generally a better fit for support processes. Queues should be designed around response times rather than solution lead times for best results.

Capacity and work-in-progress (WIP) limits should also be clearly articulated. You should also have a clear plan of how to handle situations where capacity or WIP limits are insufficient to meet your defined Service Leval Agreements (SLAs).

Agility and Fixed Guarantees

You can certainly adopt agile practices for maintenance, but SLA guarantees per se are (by definition) not iterative and not agile. Agile frameworks are about improving estimates and continuous process improvement; they are not designed to guarantee fixed lead times.

With that said, while Scrum is a project management framework, an agile framework like Scrum or Kanban can certainly be used for support with a large number of caveats. Scrum in particular is largely focused on estimating capacity based on time-boxed iterations, which isn't particularly conducive to dealing with high-priority issues that arise mid-Sprint. Handling support while a product is being developed is certainly part of Scrum, but I wouldn't recommend it for a support-only process.

Queues and WIP Limits

Kanban is somewhat of a better fit for support processes, insofar as it's queue-based. As maintenance issues are found, they are enqueued. With Kanban, you have the flexibility to design queues that map to your service level agreements, but again with some caveats. In particular, Kanban is optimized for queues with predictable variability in story size. Support and maintenance tickets would therefore need to be aggressively managed and decomposed into bite-sized pieces in order to maintain flow.

In my personal experience, an SLA should guarantee response time rather than promising a fixed time-box for results. With Kanban, that could be accomplished by adding a few queues such as "Triage" and "Respond to Customer", and ejecting or pausing work-in-progress (WIP) items from other queues when your high-speed queues are full.

Managing Expectations When Capacity is Exceeded

It's important to understand that there's no free lunch. Regardless of your methodology, your team needs to have sufficient capacity to manage the maximum WIP you are expected to handle within your SLA. If you exceed those WIP limits, then you must have a defined process for managing your WIP limits. This may be via transparent communications with your internal or external customer, or (in some environments) may be handled as business risk with attendant costs such as customer refunds. No matter how you handle it, or what your planned capacity is, it is always possible to exceed your queue size or WIP limits, so you must decide ahead of time how to handle that.


Kanban is suitable for software maintenance work

Scrum is not suitable for software maintenance. Kanban is.

Kanban was developed at Toyota in Japan to improve the auto assembly line.

David Anderson literally wrote the book on the use of Kanban in Information Technology (IT).

From David Anderson Interview: The most commonly cited instance where Kanban is extremely successful is software maintenance. Anderson says this involves fixing production bugs and doing small incremental improvements. Kanban works well with software maintenance because such work isn't a natural fit for projects and one to four week sprints. Anderson says, "It makes more sense just to take the requests, work on them, and when they're ready, find some way of deploying them to production."

Kanban has only a few principles:

  1. Visualize the workflow: You cannot improve what you cannot see. Knowledge work needs a way to visually show the status of each task. Kanban boards are one way to display this progress.

  2. Limit Work In Progress (WIP): Minimizing WIP improves throughput.

  3. Measure the lead time: Cumulative flow charts are very useful for this purpose. And look for ways to make continuous improvements in small increments.

Here is a good slideshow outlining not only how Kanban can be applied for software maintenance work, but also how to make it fun!


Although I'm posting a response a year after the question is asked, but this seems to be a common question and hope my experience would help some people in taking the right decision for their respective organizations.

According to me, here is a mix that works best for maintenance projects:

1). Define a sprint cycle - week or 2-week cycle depending on the volume of work, time it takes to fix/test/release, the number of resources you have in your team and the client's perspective/expectations.

2). Plan and re-plan sprints as often as possible to be on top of the estimates v/s current status. You'll also arrive at velocity or capacity to deliver in a few weeks time, which will further help you in planning.

3). I would not recommend use of Story points for maintenance, as hourly estimate works better in this case, since you exactly know what needs to be fixed and how much efforts are required, rather than going for relative-estimation techniques.

4). Use Kanban Board to keep a track of progress of tickets/incidents.

5). Daily stand-up meetings would help to resolve smaller or urgent bottle-necks while the Retrospective analysis would help to gradually improve the process.

6). Too much focus on process may also lead to bottleneck at times since you tend to lose the flexibility and agility. I recommend to be flexible enough to accommodate changes to sprint as long as nobody(other than process) is getting hurt.

In a nutshell, lots of wonderful tools, techniques & processes are available, you would want to choose only the ones that would really help you and your business.

Best, Nitesh

  • I disagree with your point 3, in particular that it is exactly known how much effort is required. In my experience, most of the effort goes into analyzing what the cause of the problem is. Unless you take all the analysis work out of the sprints, you generally don't know how much effort is needed to fix a problem. Dec 1, 2016 at 12:45
  • Dear Bart, Regarding point 3, you might be correct . It is important to know whether the scrum master who is performing the scrum estimate is techie or a non-techie person. In case of maintenance product, most of the fixes are known rather than items requiring a research. The support team consists of mostly technical staff who perform quick hourly estimates of their new ticket items. Theories apart, as per my experience, in case of maintenance projects, hourly estimates work best. I still prefer story points in dev projects. I urge scrum managers to choose options that would really help. Dec 5, 2016 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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