Every sprint we have 1 person in rotation for bug duty. It works quite well. Overtime role takes some refactoring and tech depth as part of bug duty.
I have a blog post on the subject a while back: https://blog.rstankov.com/bug-duty-process/
I have a blog post on the subject a while back: https://blog.rstankov.com/bug-duty-process/
We have one "on duty" person each week/half-week/two-weeks. Their priorities are:
1. Support tickets.
2. Whatever they want (usually code cleanup).
They aren't expected to get any project work done. We also track the amount of time that they are spending on support tickets. If it is getting high we move more cleanup tasks into the regular project work cycle.
If you have oncall you can often co-locate these as well (oncall is priority 0).
The main risk is that if your support load gets high than there is no room for cleanup/automation which can become a feedback loop causing more support load. I haven't seen a good solution for this other than keeping track of the load and scheduling proper "project work" to address it when it gets too high.
This is part of the process. If an issue requires deeper work, it moves a proper task in a sprint.
We try to fix the easiest issues first so the deeper problems bubble up.
How the person in the support role knows that an issue is deeper? It comes from experience. Thus everyone does 1~2 week of support.