A lot of these answers focus on Boss Management, I am going to take a different approach.
The Answer, directly
First to answer your question, your answer should be, "Of course I agree to work weekends if it means meeting a sprint deadline." The reason for that is clear (to me).
From a coders standpoint
A sprint, when used correctly, is a "deal" between (in this case) coders, and non-coders, about when a set of work will be done. It's a wonderful tool, because while, in the real world you need to be flexible, once the sprint starts the finish line doesn't move. In addition to that, in order for a sprint to be used correctly, the "coders" (either individually or as a team via a lead) get to have a major, nearly exclusive, impact on what goes into a sprint. Now the company (or client, or whatever) may want you to do more in a sprint, and that can be a goal to work on, but that doesn't matter. If all you can do is one task in a sprint, then that's all you agree to.
Here's the layout I use. I have a weekly sprint (in this example) with work due Monday. I look at the backlog (or what ever) and put enough work in the sprint to fill 4 days. That means, Monday - Thursday, I have a full workload. Not overfull, just full. Mondays, I put a little thin because we have the sprint setup and tear-down meeting(s), and Fridays, I do not schedule any work at all. This leaves me with 1 full day, with technically nothing to do.
In the real world, that extra padding, means I don't have to work weekends, and that Fridays are usually "code light" days, where I am just covering things that got delayed the rest of the week. The rest of the day I can spend do administrative tasks, like looking ahead to the next week and preparing for the next sprint. Of course, if something happens, and I need an "extra day's work" to finish of my sprint tasks, it's not a big deal. Yes, it means my normal "administrative Friday" becomes a "scramble to get it done Friday", but these things happen from time to time.
From the company perspective
So as management in the company, what you really care about are "costs" and "deadlines". Sprints are a great way to figure out what a deadline is from a process that is still largely "magical" to anyone who doesn't write code. What they see, is stuff goes on the list, I get a date, things magically work because these people make it work. The point is, most companies don't care what the due date is, so long as your hitting it, and it seems reasonable.
Costs on the other hand are a big factor. If the company has to pay overtime (in the US even a salaried employee is entitled to compensation for over time if it's constant), then it quickly becomes better to hire a new employee, rather then pay over time, or have to deal with the uncertainty of "flex time".
The company, as a whole should benefit from having a more stable cost base, and a better "completion rate" of sprints, even if that means fewer tasks get done per sprint.
If your having a lot of problems where your not getting your sprints done on time, then you (or your company) are not doing sprints correctly. You should be able to always complete a sprint, even if it means a "shorter distance". There are other metrics (i.e. velocity) for getting more done per sprint.
Remember that a sprint is "both sides". Your agreeing to do X by the end of the sprint. Either don't agree to it (break X into smaller pieces) or do what you said you would, even if it means loosing your weekend. At the same time, the "extra work" is not part of that sprint. Make sure to point that out.
Sometimes you will fail a sprint. These things happen. In my opinion, you should be ready to work the weekend in these cases. At the same time, the company should be able to respond to a few missed deadlines. It really comes down to credibility. Are you "working the hours" or are you "working the project"?
"Extra work" is common enough, it can usually mess up a good plan, but that's why I suggest the "extra day" of padding. Sometimes you won't have a lot of coding to do, and you can focus on ticket and documentation quality, or prep work. Some times, you can spend it handling issues like this (in your question).
If this extra work happens a lot then you can address it by pointing out that the sprint is how you setup your due days, and that you shouldn't move the finish line. If it happens a lot then you have a management failure, and you should ask something like "What can we do to better plan our sprints so that we don't have this Jack-in-the-box so frequently?"
Coding is a job where your just gonna have to suck it up some times (there are others). Things happen and your going to have to work more then your 40 hours. You should be ready and willing to do so. Your boss/company has every right to ask, and you have every right to say no, but saying no will look really bad. The key is to make sure that you mitigate and lesson the times that this has to happen. There will always be critical times, but you can usually reduce the number of times to something more manageable. If you feel it's happening too much, then address that by trying to work that "extra" work into your normal sprint workflow. If it's only once or twice a year, then, just deal with it, it can be a powerful tool (you working the weekend on occasion) when you need that extra couple of days off for your fantastic vacation.