本节书摘来自华章出版社《敏捷可执行需求说明 Scrum提炼及实现技术》一 书中的第3章，第3.2节，作者：（美）Mario Cardinal，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.2 应用短周期反馈环
为了实现考虑周全的探索过程，敏捷框架（例如Scrum）力求采用严格的试错流程。他们通过短周期反馈环不断地根据干系人的需求说明检查和调整软件。频繁的反馈环提供给人们以最小的成本代价修正错误的能力。团队的责任是不仅要从问题中学到教训，还要帮助干系人理解团队正在给他们构建的是什么。对于需求探索来说，需要很早就启动不断循环的反馈环。
在Scrum框架里，一个反馈回路就是一个Sprint。如图3-1所示，一个Sprint就是一个可以交付产品增量的迭代时间盒。
同一个项目里，每一个Sprint的周期都是一致的，大概是一个日历月（或更短）。它们以同样的节奏依据需求进行检查。新的Sprint从上一个Sprint结束后马上开始。Sprint引起的反馈环使得团队能够根据干系人的愿望进行调整。
最好的反馈环来自干系人跟团队一起检查和调整正在进行中的Sprint。每个Sprint，团队都在构建为干系人带来价值的功能。这些能够运行的功能以迭代的形式进行交付。可运行的软件是用来帮助挖掘理想结果的基本机制。Sprint促进开发团队和干系人之间的对话，建立了一个更好地了解后者的认知。当干系人能够尽早看到可运行的软件时，就会产生强大的且重要的反馈环。干系人们通过真实的软件来进行试验，产生新想法，并改变他们的旧想法和认知。
反馈环和发布
很多开发团队都以一个由若干Sprint组成的发布为周期交付软件。笔者的观点是，一个发布应当交付单个Sprint的产出。不幸的是，在许多组织里，发布与Sprint之间仍然存在着差别。因为有许多约束使得团队无法以Sprint的节奏部署软件。结果，只有发布才能交付可工作的软件。在这种情况下，就会有两种反馈环：发布反馈环和Sprint反馈环。Sprint和发布之间的区别并不可取，因为它降低了团队拥抱变化的能力。干系人不能参与研发团队的每月一次的Sprint里。
