You’ve got a product backlog as long as your arm but the system is live and operational demands keep landing on the developers doorstep. What to do?
Many development teams have to cope with operational commitments in addition to their new work. This is inconvenient but reality. Basically you need a mechanism to get operational work through the process despite high priority new development. There are a few mechanisms to enable this.
Operational work when running Sprints
I mentioned a few ways to cope with operational issues when running Sprints in my article on Agile Project Planning.
Different Agile Teams manage operational work in different ways but after some experimentation I found there are three general approaches to this problem:
- Lower predicted Velocity to allow spare capacity to do ad hoc operational tasks.·
- Include explicit operational items as User Stories in the Release Plan (and/or Timebox Plan) and schedule them as normal.· But if nothing comes up then get the people to work on new development.
- Have whole Sprints dedicated to operational issues. During normal Sprints no work is done on operational issues; any operational issues are just added to the Release Plan as User Stories to be dealt with in the future operational Sprint. When there are sufficient operational issues the Agile Team spends an entire Sprint dealing with them.
All of these methods have pros and cons. Just pick one that suits your context.
Operational work when running Kanban
A Kanban team does it slightly differently. The operational issues are tickets (Kanban cards) on the board like everything else. This is the same as Method 2 for the Sprint guys. But a Kanban team imposes rules about how to manage these operational tickets in diferent ways to normal tickets.
The team has to decide how many operational tickets are allowed on the board. This is, of course, a Work-in-Progress (WIP) limit in Lean-Kanban speak. A good WIP limit for operational issues is probably a small number (e.g. one) otherwise they will swamp new development. Other operational issues over the WIP limit will have to wait their turn off board.
The team also has to decide what priority these tickets have compared to new development. Often the operational issues will be the highest priority to ensure they are expedited. What that means is pulling the ticket, i.e. working on it, trumps doing other things. These tickets should have the fastest lead time.
The result of these rules means the team effectively creates capacity for operational issues on the fly. A bit similar to Method 1 for the Sprint folk which pre-plans capacity but if it isn’t used then get those people to build new stuff.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.