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

Question

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?

Answer 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