Scrum是一种敏捷方法，旨在指导团队进行产品的迭代和增量交付。通常被称为“敏捷项目管理框架”，其重点是使用经验过程，使团队能够快速，有效，有效地做出改变。传统的项目管理方法确定了需求，以控制时间和成本; 另一方面，Scrum修复了控制需求的时间和成本。这是使用时间框，协作仪式，优先产品积压和频繁的反馈周期来完成的。整个项目中业务的参与至关重要，因为Scrum在很大程度上依赖于团队与客户或客户代表之间的协作，以精益 (Lean) 方式创建合适的产品。
我们首先应该清楚Scrum不是什么。有一种常见的误解，认为敏捷就是 Scrum。虽然Scrum确实很敏捷，但它并不是实现敏捷原则的唯一方法。Scrum只是产品开发的众多敏捷方法之一。其他方法包括极限编程（XP），晶体，特征驱动开发，DSDM Atern等。所有这些方法都遵循敏捷宣言及其相关原则。一个有用的比喻是认为敏捷是冰淇淋 (ice Cream)，而Scrum，XP，水晶 (Crystal) 等，都是不同的口味，如巧克力，草莓，香草。它们都很敏捷，它们都很好，很多都可以组合使用。
简而言之，Scrum是一种灵活的迭代和增量产品交付方法，它使用频繁的反馈和协作决策。
Scrum基于1986年由Hirotaka Takeuchi和Ikujiro Nonaka撰写的题为“新产品开发游戏” 的哈佛商业评论的论文。在本文中，作者用橄榄球运动作为比喻来描述自我的好处。组织团队进行创新产品开发和交付。Jeff Sutherland，Ken Schwaber和Mike Beedle从本文中提取了这些想法，包括隐喻，并将其应用于他们的软件开发领域。在橄榄球术语之后，他们称他们的新方法为Scrum，这个术语描述了球队如何形成一个圆圈并且让球再次发挥作用。他们在1993年首次在Easel公司应用了这种方法.Schwaber和Beedle在Scrum的敏捷软件开发一书中写下了他们的经历。2002年，Schwaber 在2004年与Scrum一起出版了敏捷项目管理书，其中包括Schwaber与Primavera合作完成的工作。
Schwaber将Scrum称为框架而非方法论。这主要是由于“方法论”这个词的内涵，许多人认为这些词汇本质上是规定性的。相比之下，Scrum只提供了一个交付结构，但并没有告诉你如何做特定的实践，而是将其留给团队来确定。图1显示了基本的Scrum框架。
图表1. Scrum Process Canvas
该项目始于企业提供的清晰愿景，以及按重要性排列的一系列产品功能。这些功能是产品待办事项的一部分，由客户或客户代表（称为产品负责人）维护。通常称为迭代或冲刺的时间框是团队必须完成所选功能的设定时间量。短跑的长度通常为一到四周，并且在整个项目的整个生命周期中保持这个长度以便建立节奏。团队从产品待办事项中选择它认为可以在sprint中完成的项目，并在sprint规划会议中创建包含功能和任务的sprint backlog。
一旦团队致力于sprint积压，任务工作就开始了。在sprint的这段时间内，团队可以免受中断，并且可以专注于满足sprint目标。不允许更改sprint backlog; 但是，可以更改产品积压以准备下一个sprint。
在冲刺 (Sprint) 期间，团队每天以15分钟的会议（称为scrum Standup）的形式互相讨论和沟通。团队围成一圈，每个成员都说明了他们昨天做了什么，他们打算今天做什么，以及他们的方式是什么。
在sprint结束时，团队将他们完成的工作演示给利益相关者，并收集反馈，这将影响他们在下一个sprint中的工作。他们还举办了一次回顾展，以了解如何改进。这次会议至关重要，因为它的重点是Scrum的三大支柱：透明度，检查和适应性。
Scrum中只有三个角色：ScrumMaster，产品负责人 (Prodcut Owner) 和开发团队 (Development Team)。
ScrumMaster是流程的守护者，团队的倡导者和团队的保护者。他们消除障碍，促进团队沟通，调解团队内部的讨论，并与团队外部人员进行协商。最重要的是，它们存在于团队服务中。
产品负责人 (Prodcut Owner) 代表客户的声音，并有权决定产品。此人拥有产品待办事项，负责将愿景传达给团队，并定义积压项目并确定其优先级。产品负责人每天与团队合作，回答问题并提供产品指导。
该开发团 (Development Team)队由七个正负两个人组成，他们共同负责产品的交付。他们拥有估算，做出任务承诺，并在每日Scrum中相互报告每日状态。它们是自组织的，意味着结构在没有外界明确干预的情况下出现。换句话说，团队拥有如何选择构建产品功能 - 团队拥有“如何”，而产品所有者拥有“什么”。
Scrum通过一系列仪式 (Scrum Ceremonies) 或会议 (Meetings) 来应用。必要的Scrum仪式包括sprint计划会议 (Sprint Planning)，每日scrum (Daily Standup)，sprint审查 (Sprint Review) 和sprint回顾 (Sprint Retrospective)。还需要使用称为冲刺的时间框。发布计划会议是可选的，允许规划和预测冲刺组。
Sprint计划会议
冲刺计划会议在每个冲刺的第一天举行。ScrumMaster，产品负责人和团队都出席了会议。产品负责人提供他或她希望在sprint中完成的功能集（“什么”），然后团队确定实现这些功能所需的任务（“如何”）。将审核工作估算，以确定团队是否有时间完成sprint中请求的所有功能。如果是这样，团队承诺冲刺。如果没有，优先级较低的功能将返回到产品待办事项中，直到sprint的工作负载小到足以获得团队的承诺。
跟踪进度
一旦冲刺计划 (Sprint Planning) 会议完成并且团队做出了承诺，团队就会开始使用高度可见的信息辐射器跟踪其进度。这些散热器包括燃尽图和任务板。
团队使用任务板跟踪每个功能的任务进度。使用的最小列是“待办事宜”，“执行”和“完成”。团队将在任务委员会举行每日Scrum会议，并在陈述他们昨天做了什么，他们打算今天做什么以及他们正在努力解决的障碍时，全面移动项目。有关软件开发项目的示例任务板，请参见图2。
图表2. Scrum任务板示例
燃尽图显示了冲刺中剩余工作量的趋势线。x轴是sprint中的天数，y轴是sprint规划会议中定义的所有任务的小时数。在冲刺期间，指示剩余工作量的线应该在冲刺的最后一天趋势下降到零。有关sprint burndown图表示例，请参阅图表3。
图表3. Sprint Burndown图表示例
使用燃尽图表，任务板和每日Scrum跟踪Sprint进度。结合起来，这三件事可以清楚地描述正在进行的工作，已完成的工作，仍有待完成的工作，是否能够及时完成，以及可能阻止团队满足其冲刺和/或发布目标。
Sprint评论 (Sprint Review)
在sprint结束时，团队邀请利益相关者参加sprint评审会议，在会议中演示sprint中完成的功能并请求反馈。产品负责人会跟踪反馈并根据需要将其合并到产品待办事项中。
一旦审查完成，团队（没有利益相关者）进行回顾，以确定他们希望继续做什么，他们挣扎的是什么，以及他们对未来的改变有什么建议。创建一个行动计划，这些项目将在下一个sprint的过程中实施，并在下一个sprint回顾中进行审查。
发布计划 (Release Plan)
发布计划也是Scrum的一部分，是一种对包含多个sprint的时间框进行长期规划的方法。这通常是按季度完成的，本季度的结果不一定是向客户发布的，但可能只是内部版本以确认系统集成和验证。图表4显示了发布计划如何适应Scrum框架的其余部分。
整个团队参加发布计划会议，产品负责人在会议中展示他/她希望在本季度完成的功能。然而，该团队并未对这些功能进行任务，而是提供总体水平估算，以确定在什么样的冲刺中可以完成哪些功能，以及在本季度末可以完成多少这些功能。发布计划可以是功能驱动的（完成这组功能需要多少冲刺？），时间驱动（我们期望在截止日期前完成多少功能？）或成本驱动（考虑到这个预算，我们的日程安排是什么样的，我们在没钱之前会做些什么？）
图表4. Scrum中的发布计划
