What is inturrupt buffer in scrum??

The idea of an interrupt buffer has been written about by Scrum, Inc. and Mike Cohn. The idea is that some capacity is set aside for urgent, unplanned work that may appear within a Sprint. This can be helpful to allow the team to address user requests or to perform operational or support work. It can be a useful tool in some situations, but if the team is frequently being interrupted with work that cannot wait for the next Sprint, I'd want to understand why this is happening and try to prevent it. Urgent support requests could be indicative of product quality, urgent change requests could indicate that the Product Backlog isn't properly ordered, as two examples. It could also be helpful to look at the Sprint length and make sure that the stakeholders and Scrum Team are synchronizing frequently enough to adapt to changing circumstances.

As the term is not in the Scrum Guide, I would say that Scrum itself does not mandate; however, if its a technique that could be useful to the Scrum Team, then Scrum would not prevent its uses as Scrum is a framework that can make use of techniques and methods. 

The following blog might be what you are looking for;.  https://www.scrum.org/resources/blog/mythbusting-how-calculate-buffer-u…

In one team we had this, because we were a multi-product team, and called it "the sidelane". Every team member could work in "the sidelane" one day per week. But did not have to, if there was nothing to be done.



So when a request for a product -that was not the product we were currently working on- came in, we would write it down, we try to understand how urgent it is, and assigned it to that one day when we didn't work on the current product.



This way, we could solve problems such as bugs, new features, configuration or explanations, to name a few, "now" rather than the next period we work on that product again (which may be many months in the future).



If your team is not a multi-product (and multi-stakeholder) team, why would it be needed? You just put the issue on the Product Backlog or add it to the Sprint Backlog if it is urgent.

The problem with contingency buffers is they can reduce transparency over work in progress. Unplanned work is often hidden in them to cover up an organization’s problems.

Having a sidelane can potentially help with transparency but only if it captures teachable moments. Usually it’s just a push lane.

My advice is to plan adequate contingency into Sprint scope, whereby adjustments and sacrifices can be made (pulled) while still allowing the Sprint Goal to be met.

I and my team started scrum just under a year ago. We have a lot of technical debt in form of deprecated systems, that are still used today, but have not been lifted to newer technology, and thereby deprecated and broken. We spent way more time than we'd like to actually solve issues on these systems.

The Scrum Guide itself does not mention anything about any "interrupt buffer", but the concept does make sense in environments where daily operations cannot be avoided.

As Thomas Owens mentions, it would make sense to investigate why thesis interruptions eep coming, and whether or not it can actually wait until the next Sprint to begin. It just so happens in "reality", that sometimes bugs and breakdowns on existing systems occur, and I'd say it's up to the team to evaluate how critical this issue actually is, and whether or not it can wait.

We have members on the team that have been within the organisation for over 10 years, and these team members have a certain level of understanding of the systems breaking, since they're the ones who developed these systems. Therefore, these team members have one day per week as a buffer. They should not spent more than one day per week, unless it's a critical or fatal breakdown that resolves in multiple services not working. This is up to the team to decide.

Various processes, techniques and methods can be employed within the framework

There could be many practices like this followed by different teams within Scrum. It is better not to mention such practices as Scrum as that may not fit for all the teams or not used universally in the same way.

Thank you Thomas & everyone for your inputs.

Gone through each one of the replies.  Much clear now. 

Just want to add- The below video link shared by Scott is very useful. I would request everyone to go through this video.

https://www.scrum.org/resources/blog/mythbusting-how-calculate-buffer-u…