How to handle Tickets during Sprint Planning?

Overview

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 –

Kanban BoardHere, 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 –

Kanban Board

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

Share the Knowledge

LinkedIn
Facebook
X
Email
Pinterest
Print
Picture of Mahesh Singh

Mahesh Singh

Mahesh is a NimbleWork co-founder who hasn’t held a steady job for a long time and consequently, has run Product Management, Consulting, Professional Services and now the Marketing functions at NimbleWork. He is a Project Management and Kanban enthusiast and holds the Kanban Coaching Professional (KCP) and Accredited Kanban Trainer (AKT) certifications from Kanban University. Follow Mahesh on Twitter @maheshsingh

Simplifying Project Management!

Explore Nimble! Take a FREE 30 Day Trial

Other popular posts on Nimble!

Overview

Share the Knowledge

LinkedIn
Facebook
X
Email
Pinterest
Print
Picture of Mahesh Singh

Mahesh Singh

Mahesh is a NimbleWork co-founder who hasn’t held a steady job for a long time and consequently, has run Product Management, Consulting, Professional Services and now the Marketing functions at NimbleWork. He is a Project Management and Kanban enthusiast and holds the Kanban Coaching Professional (KCP) and Accredited Kanban Trainer (AKT) certifications from Kanban University. Follow Mahesh on Twitter @maheshsingh

Simplifying Project Management!

Explore Nimble! Take a FREE 30 Day Trial

Other popular posts on Nimble!

We are on a Mission to
#HumanizeWork

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives

Subscribe To Our Newsletter

See Nimble in Action!

Conduct Retrospectives
Contact Us

See Nimble Agile in Action!

Conduct Retrospectives

We are on a Mission to #HumanizeWork

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives