We are moving to SCRUM - in our sprints, we work on a version 1.1, while version 1.0 is being in production. However, ocassional bug from version 1.0 is reported and have to be fixed. I found no information about how this should be handled - it does not seem right to me to make them part of the sprint (as they are from a different version and have nothing to do with sprint goals in the current sprint) but how to approach them then? Basically, it could be extended to maintenance work on versions that are already deployed.
I don't know if there's an officially Scrummy was of handling that, but what I've done in previous teams is the following:
Set some time aside
Production issues are a reality whether or not we want to admit it. As such, the only sane thing to do is factor them in your planning.
When planning your sprints, reserve a percentage of developer effort for handling production issues. Just how large a percentage will be very specific to the product and the team. So, this value is one of the things you'll need to tweak from sprint to sprint.
Not all production issues are created equal
When a production issue crops up you should assess its impact before deciding how to deal with it.
- If the issue is a Blocker it will need to be fixed immediately
- If, on the other hand, the issue is minor, or there is a known workaround the users are happy to put up with then the new issue goes into the product backlog
That last point is very important. I've seem teams fail sprints repeatedly simply because they always prioritised production issues over everything else.
The whole point of having short sprints is so that you can work on them with minimal interruption. Of course, you need to be pragmatic (eg, addressing blockers) but you also need to be careful not to put your planned sprint at risk.
It's very much a balancing act.