Scrum要求在sprint中的干扰尽量少，这样团队可以高效工作以达成他们的目标，
由干扰驱动的开发
。Scrum master负责去除可能影响团队速度的障碍。然而在实际情况中，团队开发出新功能并供以发布的同时，他们还要面临产品支持方面的问题。对于团队来说，这些干扰也许只是分散注意力的小问题，而对于系统用户和产品负责人来说，它们却是非常重要的问题，必须解决。产品负责人会觉得：在现有系统不能正常运转之前，添加新功能是没有意义的。Scrum Alliance wiki中列出了一些干扰的例子，比如：
一线技术支持人员无法完成技术支持工作
系统维护任务
对于调查奇怪的系统行为方面的要求
对于系统数据方面的要求，这些数据难以获得而且需要开发人员参与
客户的定制要求
需要开发人员解决的产品问题（例如系统当机或性能低下）
上面列出的所有场景，都有可能演化成比开发新功能更重要的问题。那么在sprint中该如何应对这些干扰呢？
Geoff Watts就如何在Scrum中应对这些干扰给出了自己的想法。
使用两个backlog——一个供开发功能使用，另一个供解决产品支持问题使用。产品负责人定义每个backlog中要完成工作的比例。
这个方法需要团队使用两个燃尽图，一个供开发用户故事使用，一个供产品支持使用。
将bug作为功能请求——干扰可以放置在产品backlog中，并带有估算的业务价值和大小。Geoff建议在使用这种方法时，要排定产品支持的问题与其他功能之间的优先级。他指出：此处的关键是要避免陷入争论，不要争论到底是产品支持的问题重要还是其他更重要。团队要理解、吸收有关优先级排定的讨论，而不是在二者之间划出分界线，这样才能取得更好的效果，同时更有工作效率。
紧急状况——有些干扰必须马上解决。Scrum master和产品负责人是紧急状况的最好判断者。
如果发生的问题真得很紧急，产品负责人有权力打出“紧急状况”这张牌，只要他能够意识到这样做的代价——无法完成预先规划的功能，而且有可能无法达成sprint的目标。另一个重要的问题是：“谁应该负责解决这些干扰？”产品支持很无聊，团伙成员也都不太愿意去干这个。那使用支持团队这个主意怎么样？Geoff说：“使用支持团队会造成不必要的隔离，而且会带来混乱。”可以在团队中设定一个支持者的角色，在每个sprint或每周的工作中发挥作用。这也可以增加团队的跨职能行为，同时还有益于提升系统的整体知识水平。
对于应对干扰，Alistair Cockburn提出的另外一种解决方法是：使用名为“牺牲一个人”的项目管理模式，
管理资料
《由干扰驱动的开发》(https://www.unjs.com)。他认为：解决问题的方法，是任命一个人专门解决这些干扰。虽然这个人可能觉得自己被牺牲了，团队其他人却可以通过处理主要的问题来取得进展。总的来说，关于如何应对干扰，可以考虑将它们放到产品backlog中，并基于其业务价值排定优先级。这可以保证团队一直在做正确的事情。然而，如果干扰是紧急事件，那就要考虑一下解决成本了。要权衡马上解决对整个项目造成的影响，再做决定。
查看英文原文：Interruption Driven Development
对于这个话题，InfoQ的读者Kurt Christensen给出了自己的解决方案：
对于进行中的维护工作，我使用起到占位符作用的故事（placeholder story），并取得了很好的效果。在sprint的开始，团队会根据上个sprint中的经验，估算出维护工作可能占用的时间。对此，Kevin E. Schlabach指出：
我也让我的团队使用了同样的方法。这样团队就能够解释为什么不能完成预期规划好的工作（当维护工作占用的时间不断变动时），基于此而得到的开发速度也是可以达成的，这对团队来说也是个激励。这样做的负面效果是产生了不必要的开销（浪费），仅仅能够解释正在发生什么。有时，这样做几乎没有任何价值。因为团队和管理层根据过去的经验，接受了“支持速度”，并继续跟踪记录这个速度，这也变成“为了流程而流程”的一部分。所以我建议，大家要用时间盒来限制其时间，而且要进行回顾，看看如何减少其时间，能够接受多少这样的干扰作为正常的业务，以及如何不再对其进行记录以简化流程。最终，我希望团队可以将开发速度上的目标降低某个点，并接受由于支持工作造成的损失（能够做到自我管理的团队可以产生应对之策）。
对于Alistair的建议，我想他也一定支持这应该是个轮换的角色（每个迭代或是迭代中某个时间段）……重要的是，要让团队中最重要的人先来承担这个角色，这样大家都能清楚地知道该角色举足轻重。不要让新人或是能力稍差的人先做该工作。否则就会影响到团队的干劲儿，形成分裂：一些人是专门负责开发新功能的超级明星，另一些人则负责支持工作。
有读者Dean Wampler说：
我正在与这样的团队工作，开发人员和项目干系人都花了很多时间来处理类似的工作。我们试图跟踪记录这些努力，看看哪些部分可以通过自动化得到改进，让管理层知道“时间都花在什么上面了”。对此，InfoQ资深编辑Deborah Hartmann指出：
我曾工作过的某个团队曾经遇到过类似问题。他们决定在任务板上放置浅绿色的任务卡，每一张对应一个干扰。两周之中就累积了N多绿色的卡片！仅仅一个sprint过后，团队达成一致意见，要先解决掉这些干扰。这样做使得问题的规模暴露在众人面前。他们很快就不用绿卡片了，因为不再需要了。从那时起，干扰就被分类了：支持工作会被放到支持“桶”中，而其他的干扰则会这样应对：“是的，我们会把它放到下个sprint中完成。”来自：http://www.infoq.com/cn/news/2008/07/interruption-driven-development