Which strategies I can use to handle tickets during a scrum sprint?

Question

My 4 man team directly handle most technical tickets, with a SLA from 8 hours to 24 office hours, means that during a sprint we must add these tickets in top of our current sprint backlog. We have one dedicated person which handle commercial tickets and easy problems, however he cannot handle specific questions/problems.

These tickets greatly affects our velocity and demoralize team members that cannot measure their effort.

Most tickets aren't bugs, they are just problems related to the product, for example recently we wasted 3 day debugging a client issue, to later find out that was a broken RAM module.

How can I keep the team motivated and measure the actual velocity without breaking the SLA?

Answer 1

Budget time for such production bug triage work

This is not very unusual. Most software development teams have to be prepared to fix production bugs on priority, if any are reported. It is also quite normal that bug reports need to be triaged first even though some of them may turn out to be not bugs at all. However, your team seems to have more of them with tighter SLAs.

Here is what I will do in your situation:

1. At the time of Sprint Planning keep aside bandwidth for such bug triage work. You can take a look at the % of time spent on such work in the past few weeks/months and base it on that. If there is a lot of such work, look into whether one of the 4 man team needs to be dedicated for this work.
2. Also, keep some stories fully ready and planned but not in the Sprint backlog but on top of the backlog. One of these can be pulled in if it appears mid sprint that it will be possible to take it on.
3. When the bug ticket comes in, estimate it just like the other stories. This way you will have a record of how much work has been accomplished during the sprint.
4. Is that dedicated person using a Kanban board for handling the commercial tickets and easy problems? If not, consider using one.

Answer 2

I think you can find interesting reading the following article: Applying Agile in a Mixed-Feature Development and SLA-Bound Bug-Fixing Team

I believe that having a dedicated team member that deals with tickets is a good solution to the SLA problem. By doing so, the other three team members can keep the sprints uninterrupted.

Most developers do not like working solely on support issues. In order to avoid that the morale of the "support developer" could suffer, you have correctly chosen to use the round-robin principle. It is wise to do so for another reason as well. Without rotation in this task, many bugs will be handled only by the same "support developer", and the remaining developers could start to pay less attention to code quality.

The "support developer" could use Kanban to solve support tickets and create new releases faster, without having to wait for the end of a sprint.

You have written that sometimes the "support developer" is not able to handle specific questions/problems alone. Another solution can be to allocate time for the tickets in advance. To know more about how you can set aside some percentage of your velocity as an interrupt buffer, you can give a look at the Scrum pattern known as “Illegitimus Non Interruptus”.

Answer 3

If the velocity of your team is impacted by tickets, then it is important to reflect that impact in your sprint planning. There are at least two ways to do so.

Option one: If it isn't possible to assign story points to tickets, then allow your velocity to drop. Don't think of a reduced velocity as a bad thing. The purpose of velocity is to help a team understand how much work to commit to within a period of time. A low velocity team that meets its commitments is preferable to a high velocity team that is highly unreliable in its commitments.

Option two: If it is possible to assign story points to tickets, then count ticket completions toward the team's velocity. Pay attention to the percentage of the team's velocity that is contributed by closing tickets. When planning for a sprint (a new period of work), reserve an appropriate amount of capacity for tickets that the team expects to encounter during the sprint. For example, if velocity is 100 and tickets contribute 40, then only commit to 60 points of non-ticket work. During the sprint, if the team completes non-ticket work and doesn't receive the expected amount of ticket work, then the team can pull additional non-ticket stories into the sprint.

Option two is the preferable approach. Remember that the purpose of velocity is to help teams, when planning a sprint, to avoid committing to more work than can be completed during a sprint. Once commitments have been met, it is always okay for a team to pull additional work into a sprint.

As @Depressive_Bore mentioned, the answers about software maintenance will likely be helpful to you.

Answer 4

As said above this is a general scenario.

Within our 4 person team, we have a dedicated team member for handling the production bugs. His velocity will be zero for that sprint (we will track the no. of tickets which were closed by him/her). This role is carried out in round robin fashion.

The remaining team members will be taken as the velocity for that sprint.

Answer 5

Automated Testing.

As you note, most of these problems are not bugs and most of the time working on them is probably, 'figuring stuff out' rather than changing code.

Although it might seem like a time/resource management issue, actually your problem is in treating customer support as a series of technical tasks to be added to your sprint. Techies don't tend to make the best customer support guys!

In order to avoid this you need a quick and efficient test to decide whether the problem requires a code change in order to fix it and if so, what the requirements of that change should be.

Ideally an automated test suite will determine if the product is functioning as designed and can be run before and after each release.

But, you can also build up a set of manual tests by writing down steps and expected behavior and common fixes each time a bug is reported. Once you have a large set of these they can be handed off to a less technical customer support team to run through before escalating the problem