How to handle Tickets during Sprint Planning?

That was the question posed in a recent discussion. The question further provides the following details – “I work within an agile team. We have a released product and we are still working towards a future release. Every sprint we receive anywhere from 0 to 5 tickets to fix bugs in the released product. Our team is composed of software engineers (to handle new development) and maintenance software engineers ( to handle tickets).

My question is how do you account for the maintenance hours during sprint planning. Currently, we have a story called maintenance buffer where we allocate some hours to solve tickets. And we sort of use it as a buffer, so in sprints where we receive no tickets we use the hours in the buffer for development work.

I feel this is not a good agile way to do things, any suggestion?”

My Response
I agree that this is not a good agile way to do things! The question to ask is – is your real objective to plan for maintenance hours or to ensure that your team is optimally utilized working on both user stories and defects while turning out quality code on a continuous basis, including defect fixes?

My suggestion would be to use Kanban AND Scrum together – Scrumban is increasingly catching on! Since you have said you may have 0 to 5 defects in any sprint, clearly your ‘failure demand’ is variable and so is the need for your ‘maintenance engineers’ capacity. What do they do when there are 0 or 1 or 2 defects? I presume they also contribute to the ‘value demand’ – new user stories.

This is where Kanban shines. While the actual design of your Kanban board will need to be analyzed by your team, you can potentially start with a simple 2 swim-lane board that mirrors your current process for doing your work. A simple example is shown below –

Here, you have all your engineers available for working in either lanes. As work flows in, depending on who is free to take it up – and CAN take it up – they pull work in and work on it. You still batch things for the sprint at Staging – and deploy the batch at one go.

Alternately, you might have completely separate lanes for User Stories and Defects –

Here again, all your engineers work on items in both lanes. However, you have the flexibility to deploy defect fixes as soon as they are fixed and accepted by the customer (if applicable). With your value demand, you continue to follow the same process as you are now and deploy when each sprint is done.

The advantages of either of these approaches are –

1. You get a bigger pool of people to work on either situation.
2. You potentially get faster response times, better SLA performance, on defects.
3. You get a happier team where everyone gets to work on new stuff. Most engineers don’t want to be ‘maintenance’ guys 🙂

Of course, this is just based on basic analysis. If you are not familiar with Kanban or Scrumban, you should read books by David Anderson (Kanban) and papers by Corey Ladas (Scrumban) and several others like Yuval Yeret, Jim Benson, Masa Maeda and prepare yourself better. You can also connect with us at https://www.digite.com/swiftkanban/ and we can certainly help as well.

Do you agree? I would love to hear your thoughts on how you do your Sprint planning when there is both value and failure demand competing for the Sprint capacity.

Mahesh Singh
Co-founder/ Sr. VP – Product