注：本文中使用的很多Scrum术语来自台湾地区的叫法，仅供参考。
Scrum 是一个用于运行项目的框架，它基于敏捷原则和价值。 它定义一组活动，这些活动可帮助您的团队更快地向客户交付更多价值。 利用这些活动，客户有机会在您的团队开展工作时检查、指导和影响团队的工作。 此方法不会尝试在项目开始时定义所有内容。 相反，您的团队以短小迭代（也称为“冲刺 (sprint)”）为单位进行工作，并随团队工作的进展不断改进计划。
MSF for Agile Software Development 5.0 版是基于 Scrum 的。 因此，您的团队可通过使用与您的核心开发活动集成的工具来采用 Scrum。
准备项目
在开始项目之前，应执行以下任务：
建立业务个案
组建团队
设置团队的基础结构
若要建立业务个案，应确定业务需求和论证、定义远景并获得资金。 Geoffrey Moore 所著“Crossing the Chasm”（《跨越鸿沟》）一书为建立远景提供了很好的指导。
建立业务个案后，您必须组建团队并确定 Scrum 主管和产品所有者。 有关更多信息，请参见角色。
最后，您的团队必须设置基础结构。 例如，安装 Visual Studio Team Foundation Server 和 Visual Studio Application Lifecycle Management (ALM)，创建团队项目并在可能时对其进行自定义，另外，还要制定工程实践方案。
规划项目
在 Scrum 项目中，您的团队会将大部分时间用于在一系列冲刺 (sprint) 中开发产品。 但是，您的团队必须先为项目创建一个高层次的计划。 此计划是一个指导性的计划，您的团队应根据它在项目进行的过程中制定更详细的决策。 您的团队实现此计划时，它将发生更改。 您的团队完成项目的规划时，团队将创建一个产品积压工作，在需要时还将创建一个发布计划。
生成产品积压工作
产品积压工作是一个用户情景列表，这些用户情景描述您的用户需要和重视的内容。 用户情景根据业务价值和风险排定优先顺序，团队使用称为情景点的抽象单位来估计用户情景。
1、创建用户情景：Mike Cohn 在他的“User Stories Applied”（《用户情景应用》）一书中这样定义用户情景：“用户情景描述的是将对系统或软件的用户或购买者有价值的功能”。用户情景是从最终用户的角度编写的。 例如：
“作为老客户，我想要查找我以前的订餐。”
2、设置用户情景的优先级别：产品所有者应与客户合作以了解他们的需求，并与团队合作以了解风险和依赖因素，以此来设定产品积压工作中用户情景的优先级别。 产品所有者指定优先级别的方法是：为每个用户情景指派一个排名，以指示团队实现它们应遵循的顺序。
产品所有者可以使用许多方法来分析和比较用户情景的价值。 如果您的团队已经有一种适合您的设置优先级别的方法，您应继续使用该方法。
有几种设置优先级别的方法与敏捷社区紧密相关，如客户满意度 Kano 模型和 Karl Wiegers 的相对权重法。 （有关相对权重的更多信息，请参见以下网页：First Things First: Prioritizing Requirements（重要的事先做：为要求设置优先级别）。）其他设置优先级别的方法（如成本优先、净现值、回收期和内部收益率）在敏捷社区外也早已确立。 这些方法也都是可以使用的，适合对 Scrum 项目的产品积压工作设置优先级别。
3、估计用户情景：您的团队一起协作，用情景点估计每个用户情景。 Mike Cohn 在他的“Agile Estimation and Planning”（《敏捷估计与规划》）一书中这样定义情景点：“情景点是一个度量单位，表示用户情景、功能或其他工作的总体大小”。情景点是相对值，不能直接转换为特定的小时数。 但情景点可帮助团队量化用户情景的基本大小。 这些相对估计不够精确，因此只需少量工作即可确定它们，但随着时间推移它们将越来越精确。 通过用情景点进行估计，您的团队现在将能够提供用户情景的基本大小，在以后团队成员要实现用户情景时可以更细致地估计工时数。
确定团队的速度
您的团队在创建发布计划并规划每个冲刺 (sprint) 之前，必须确定团队速度。 团队的速度是它在一个冲刺 (sprint) 中可以完成的情景点的数目。
如果您的团队收集过表明团队在一段给定时间内完成的用户情景数的数据，并据此度量其速度，则应使用该数据。 它是您了解团队速度的最佳渠道。 如果您现在没有该数据但打算使用 Visual Studio ALM 和 MSF for Agile Software Development 5.0 版运行您的项目，则在项目过程中可以收集该数据。
如果历史数据不可用，您的团队可以粗略估计在第一个冲刺 (sprint) 中可以完成的情景点的数目。 应查看属于最高优先级别的已估计用户情景，并快速估算团队在一个冲刺 (sprint) 中可以完成的情景数。 为其中每个用户情景添加情景点可获取初始估计。 在第一个冲刺 (sprint) 后，您可以使用历史数据确定团队的速度。 在前几个冲刺 (sprint) 中，随着团队逐渐掌握如何一致地进行估计，变化可能非常大。 在几个冲刺 (sprint) 后，团队的度量速度应变得比较稳定。 当团队的度量速度稳定时，重新评估发布计划。
团队速度的估计值提供了一个起点，可用于确定要在冲刺 (sprint) 中实现的用户情景数，但估计值不应作为团队承诺的基础。 团队的承诺应以完成用户情景所需的任务的更细致估计为基础。
建立发布计划
在每个冲刺 (sprint) 中，您的团队将完成可交付的产品增量。 尽管您的团队实现的用户情景将在冲刺 (sprint) 结束时可供交付，但它们可能无法提供足够的业务价值来对发布该产品进行实际的支持。 将这些用户情景指派给迭代，以此来计划您的产品发布。
确定用户情景组，整组用户情景一起可提供足够的交付给客户的业务价值。
确定团队预期在哪些冲刺 (sprint) 中完成这些用户情景组。
随着团队的进展，向产品积压工作添加用户情景，并可以移除用户情景。 此外，某些用户情景的优先级别会更改，某些用户情景可能比最初预计提前或推后实现。 产品所有者应在项目过程中将发布计划与产品积压工作一起维护。
准备第一个冲刺 (sprint)
冲刺 (sprint) 是指开发所用的固定时长迭代，通常为一到四周时间，可产生团队可以交付的产品增量。 您的团队开始第一个冲刺 (sprint) 之前，产品所有者应准备产品积压工作。 因优先级别足够高而入选第一个冲刺 (sprint) 的用户情景必须已准备好供团队实现。 产品所有者必须执行以下任务来准备产品积压工作：
将用户情景分解为较小的情景。
提供团队将用户情景分解为任务时所需的用户情景详细信息。
如果某个用户情景占团队总速度的很大一部分，产品所有者将知道该用户情景过大。 例如，如果团队的速度是 30 个情景点，则包含 15 个情景点的用户情景过大，在冲刺 (sprint) 计划会议中将不予考虑。 团队仅完成该用户情景就要占用冲刺 (sprint) 的一半时间。
您的团队还要询问有关用户情景的详细信息，以便能够将用户情景分解为任务并估计这些任务。 例如，您的团队在检查用户情景“作为客户，我希望能够搜索某种类型的饮食”时，可能询问以下类型的问题：
“它是必须为任意文本搜索，还是可以从可用类型列表中选择？”
“如果有多个供应商提供与搜索相匹配的饮食，如何对结果进行排序？”
规划冲刺 (sprint)
团队在确定产品积压工作并建立发布计划后，即可开始冲刺 (sprint) 工作。 团队的冲刺 (sprint) 从冲刺 (sprint) 计划会议开始。在会上，团队承诺完成产品积压工作中的一组用户情景。 这组用户情景以及支持这些情景的任务构成冲刺 (sprint) 积压工作。
在冲刺 (sprint) 开始后，冲刺 (sprint) 积压工作中的用户情景不会更改。 因此，计划必须足够详细，以便团队有信心作出承诺。
选择用户情景
团队可选择要在冲刺 (sprint) 中实现的候选用户情景。 团队确定具有最高优先级别并且包含的情景点不超过团队估计速度的用户情景。 例如，具有最高优先级别的五个用户情景可能分别有 8、3、7、6 和 2 个情景点。 如果您的团队在每个冲刺 (sprint) 中的处理能力为 25 个情景点，则您的团队将在冲刺 (sprint) 积压工作中包含前四个情景。
确定任务
团队评估每个用户情景，以确定为实现该情景而必须执行的任务。 团队将用户情景分解为任务，这有助于团队更好地理解用户情景，从而有信心承诺在冲刺 (sprint) 中完成这些用户情景。
对 Scrum 经验非常丰富的团队可以在不将用户情景分解为任务的情况下作出承诺。
估计任务
在确定任务后，团队可估计每个任务将花费的时间（以小时为单位）。 团队经常使用计划扑克方法来估计任务。 此方法有助于防止团队尝试估计没有必要的过度精确。
承诺完成用户情景
团队使用“迭代积压工作”工作簿以确保团队有足够的工时数来完成所有任务。 如果冲刺 (sprint) 所需的工时多于您团队可用于冲刺 (sprint) 的工时，则必须移除排名最低的用户情景，直到团队可用于该冲刺 (sprint) 的工时足以容纳所需工时。 可以用优先级别较低的较小情景来代替不适合该冲刺 (sprint) 的较大情景。
团队承诺完成已确定可以完成的用户情景。 团队在作出此承诺时已了解，产品所有者不会尝试引入其他工作，也不会更改要在冲刺 (sprint) 中实现的用户情景的优先级别。
运行冲刺 (sprint)
在冲刺 (sprint) 过程中，团队将完成实现冲刺 (sprint) 积压工作中的用户情景所需的任务。 团队可以跟踪其进度，并确保在完成每个冲刺 (sprint) 之前，完成的软件满足客户的验收条件以及团队的条件。
完成用户情景
团队规划冲刺 (sprint) 后，将得到列表形式的团队已承诺在冲刺 (sprint) 过程中完成的用户情景。 这些用户情景已分解为任务。 团队的每个成员将在冲刺 (sprint) 开始时约定承担某项任务。 完成该任务后，团队成员将更新其状态并约定承担另一项任务。 通过此方式，团队将完成任务列表中的所有任务，从而完成冲刺 (sprint) 积压工作中的用户情景。 团队成员可以在签入代码时指示已完成哪些任务。
Scrum 依靠人员比在正规流程中更多地相互交谈来确保理解依赖关系、共享技术并有效地进行计划内更改。 每天召开一次简短的 Scrum 会议，在会议中，团队的每个成员可以共享以下详细信息：他们在前一天完成的工作，他们计划在当天完成的工作，可能对其他团队成员产生影响或需要获得其他团队成员帮助的任何问题或障碍。
Kent Beck 在他的“Extreme Programming Explained”（《解析极限编程》）一书中讨论了尽早比推迟修复 Bug 可以节省多少成本。 基于这一事实，团队必须了解客户关注什么。 可能客户重视的是质量而非更多功能。 产品所有者必须知道此类信息，因为客户控制团队的工作流。
Scrum 团队生产的软件应该没有错误。 但是，团队可能会在项目中遇到 Bug。 处理 Bug 时应认识到，在发现 Bug 时即修复它们要比推迟到以后修复它们节省成本而且更快速。 团队在发现 Bug 时应该立即修复它们。 如果团队无法在发现 Bug 的当天修复该 Bug，应在 Visual Studio ALM 中创建一个 Bug 工作项，并在冲刺 (sprint) 结束之前修复它。
跟踪冲刺 (sprint) 进度
团队可以跟踪冲刺 (sprint) 的进度，确保如期完工并满足验收条件。 Scrum 团队最常使用燃尽报表在冲刺 (sprint) 过程中跟踪进度。 MSF for Agile Software Development 5.0 版提供了一组供团队跟踪冲刺 (sprint) 进度的报表。
“燃尽和燃速”报表（敏捷）
团队经常会发现，自己完成某个任务所需的时间长于或短于冲刺 (sprint) 计划会议中估计的时间。 这种变化很常见。 您可以通过指定团队在任务中花费的实际时间来记录此信息。
随着冲刺 (sprint) 的进展，团队可能会发现预计之外但又是完成用户情景所必需的工作。 在这种情况中，应创建任务，估计它，然后确定团队是否可在冲刺 (sprint) 剩余工时内完成它。 如果团队可以完成该任务，则继续该冲刺 (sprint) 的工作。 如果团队无法在此冲刺 (sprint) 中完成该任务，则与产品所有者会面，讨论如何继续工作。 产品所有者和团队可以通过执行以下类型的更改来解决问题：
降低用户情景的验收条件，所以不再需要该任务。
从冲刺 (sprint) 积压工作中移除该用户情景。
取消该冲刺 (sprint)。
完成冲刺 (sprint)
在冲刺 (sprint) 接近结束时，确保团队即将完成所有用户情景或要求。 例如，确保验收测试通过，并且每个用户情景都满足团队定义的条件。
在冲刺 (sprint) 的最后一天，团队将向产品所有者（可能时还可以向客户）演示已完成的用户情景。 产品所有者和客户将确定他们是否接受每个用户情景。客户评审后，团队将保留一个追溯。
跟踪项目
随着团队在一个又一个冲刺 (sprint) 中工作而不断交付项目增量，客户将更好地了解还有哪些需求有待满足，同时必须考虑业务环境中的更改。 产品所有者与客户合作以了解这些更改。 产品所有者将维护产品积压工作和发布计划，以反映这些更改，并确保在每个冲刺 (sprint) 开始时，团队都具有所需内容。 团队跟踪整体产品进度，以确保项目如期完成进度。
准备下一个冲刺 (sprint)
产品积压工作的新鲜度与项目的总体质量和完整性有直接的关系。 必须定期更新、更改和重新考虑积压工作，以确保每次团队开始冲刺 (sprint) 时，它都可供立即使用。
产品所有者通过执行以下任务来为下一个冲刺 (sprint) 准备产品积压工作：
在客户需求更改时及时更新用户情景及其优先级。
分解可能会在下一个冲刺 (sprint) 中实现的用户情景。
当团队完成一个冲刺 (sprint) 时，其他用户情景将更靠近产品积压工作的最上层。 产品所有者必须分析和分解位于最上层的那些情景，以便团队可以在即将开始的冲刺 (sprint) 中实现它们。 （有关更多信息，请参见本主题前面的准备第一个冲刺 (sprint)。）Mike Cohn 常称此过程为产品积压工作冰山。 当团队处理一组功能时，冰山融化，新的工作浮出水面并且冰山变小了。 在此过程中，将及时出现足够的其他详细信息。
由于团队正忙于运行冲刺 (sprint)，因此产品所有者无法期待团队像在参与准备第一个冲刺 (sprint) 时那样参与维护产品积压工作。 为帮助产品所有者准备产品积压工作，同时尽可能减少冲刺 (sprint) 中断，团队和产品所有者将在冲刺 (sprint) 进行期间，就产品积压工作的打开的问题进行讨论。
跟踪发布进度
当项目从一个冲刺 (sprint) 进展到另一个冲刺 (sprint) 时，团队将跟踪下一次发布的整体进度。 团队还将跟踪自己的进度以便评估和提高团队速度。 团队在跟踪进度时，应尝试回答以下类型的问题：
我们是否在处理最合适的用户情景？ 随着项目的进展，将使用新的用户情景优化您的产品积压工作。 但是，如果积压工作中的情景总数未减少（即使您即将完成每个冲刺 (sprint) 中的情景时也是如此），则团队应调查原因。 正在完成的情景可能不是最佳选择。 团队应对每个发布有一个远景和一个目标，并确保这些情景与客户的要求直接相关。
我们是否在承担技术债务？ 即使修复 Bug 等工作尚未完成，一些团队仍将用户情景视为已完成。 这些团队承担着必须在以后偿还的技术债务，这类成本通常很高。
Visual Studio ALM 提供了几个报表，可帮助团队跟踪多个冲刺 (sprint) 的进度。
“所有迭代的状态”报表
完成发布
如果团队未累积技术债务，则可以在已完成发布中的冲刺 (sprint) 时发布产品，而无需其他工作。 团队和产品所有者召开客户评审和追溯会议以整体检查该发布。
但是，技术债务是一个富有挑战性的问题，团队无法轻松解决。 如果您的团队和许多其他团队一样仍在累积技术债务，则必须花时间处理未完成的工作，以便在发布产品之前完成用户情景。 在发布追溯中，需要考虑团队必须在即将开始的冲刺 (sprint) 中进行的工作，以避免承担更多债务。
