How to handle "tickets" during sprint planning [closed]

Question 1

The approach you have mentioned is also covered by Mike Cohn in Should Story Points Be Assigned to the Agile Defect Story?, where he writes:

Sometimes teams write a user story for this activity such as: “As a user, I want at least 15 bugs fixed” or, “As a user, I want you to spend about 50 hours this sprint fixing bugs so that the application becomes gradually more high quality.” Even a team that doesn't explicitly write such a user story will usually include a row on its taskboard to make the agile defects and bug fixing visible, and to track it.

You currently have a story called maintenance buffer where you allocate some hours to solve tickets which is something similar to what is stated in Mike Cohn's article where he recommends to assign points to bug fixing the agile defects.

There could be other options too, like

Setting some time for bug-fixing in each sprint. It could be a set time of the day/week when every team member deals with bugs.
Including each bug in the same sprint backlog by considering them as a partially implemented feature. This is discussed by Mark Summer in Managing Bugs in Scrum.

What to do in case of emergencies / hotfixes?

You need to assess the criticality and the effort required to fix that urgent bug. It is up to the Product Owner to decide if the team drops everything and starts working on the hotfix. Reason being that the customer always comes first and if the delivered product is not providing the expected value then there is no use of adding more features to an incomplete product. No framework / methodology stops you from handling exceptional cases or dictates you to ignore critical issues. So the current sprint can be cancelled or if the hotfix can be handled by one (or some) members of the team then a feature or bug, from the current sprint, can be swapped with the urgent bugfix.

In words of Geoff Watts from Production Support and Scrum:

If the issue is a true emergency, the Product Owner should have the authority to play the “emergency card,” as long as he is aware of the costs of doing so— not completing the items we planned to and, potentially, jeopardizing the sprint goal.

The Product Owner can exercise any of the 3 options:

Add the urgent defect to the backlog because he/she has decided that the current sprint goal has higher priority
Add the urgent defect to the current sprint because it is critical enough which could even jeopardize the sprint goal
Cancel the current sprint, do the hotfix, and then start a new sprint after that

Question 2

In brief, I'd raise bug(s) as a Product Backlog Item (PBI) and prioritise them against other PBI's in the Product Backlog. This way, you can always be sure that the most important things are done first.

Part of the unwritten contract of Scrum is that the business agrees not to interrupt the Development Team. This is partly how they can improve performance.

If you get a hot/urgent ticket that CANNOT wait for the duration of a Sprint, you need to convince the Product Owner who would then negotiate with the Development Team for the best way to introduce the hot item.

However, this would need to be an exception, rather than the rule. If, as you imply, you get a lot of bugs to fix, I'd be tempted to run the maintenance / defect fixing with a separate team using KanBan, rather than Scrum.

Question 3

I agree with you 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?

I would go one step further from what Derek has suggested - and 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 -

enter image description here

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 -

enter image description here

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 -

You get a bigger pool of people to work on either situation.
You potentially get faster response times, better SLA performance, on defects.
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 www.swiftkanban.com and we can certainly help as well.

Hope this helps!