Scrum完整剧本

敏捷快速入门指南

《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法，对于那些希望获得一些一般性指南（并非旨在作为说明性准则，但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题（Scrum事件）上。其他主题涵盖了作为敏捷教练经常遇到的领域。

Scrum主题

• 产品列表梳理会议快速入门指南、

• 每日站会快速入门指南

• Sprint规划快速入门指南

• Sprint评审快速入门指南

• Sprint回顾快速入门指南

其他主题：

• 故事拆分快速入门指南

• 编写清晰明确的用户故事快速入门指南

Product Backlog Refinement

简介：产品列表梳理会议（也称为需求梳理）不是Scrum指南中定义的活动。然而，产品列表梳理的实践在Scrum团队中是非常普遍，以至于一些从业者认为这是普遍接受的Scrum实践。

定义

产品列表梳理会议是为即将到来的（如接下来的1-2个）迭代（Sprint）准备用户故事的一个持续过程。产品列表梳理有两个主要方面：

由产品经理和产品负责人领导的，需求功能不断定义、完善、澄清以及重新确定顺序；

在Sprint开始之前进行的一次协作会议，以评估新信息，确保准备开发下一组故事。

频率

每个Sprint一次（通常是Sprint中，下一个Sprint开始前的1-5天不等）

注意：某些团队选择每个Sprint进行多次"梳理"会话。如2周的SPrint，可能一周梳理1次。

持续时间

团队应努力在一个小时或更短的时间内完成为期两周的Sprint的产品列表梳理。当故事在产品列表梳理开始之前就被很好地阐明时，团队更有可能在相当短的时间内完成产品列表梳理。（另请参见编写清晰明确的用户故事快速入门指南。）

参与者、输入、输出

参与者 – 产品负责人，ScrumMaster，开发团队

输入 – 主要输入是为即将到来的Sprint预测的用户故事，这些可能是后续Sprint的不错选择。处于就绪状态的用户故事要多于下一个Sprint可能会有所帮助。因此，如果团队确定依赖性，并有了影响多个故事的优先级或工作量的新信息，那么就可以灵活处理。

输出 – 整个团队达成共识，就一组排好序、清晰定义且独立的用户故事达成共识。

活动

产品列表梳理期间的活动通常包括：

查看从当前Sprint中学到的新信息

讨论最快速度、可能速度和最差速度

是否对当前的Sprint进度进行检查 - 我们是否认为我们将完成Sprint期间的所有工作？

在回答这个问题时，请牢记可持续的步伐

对于团队来说，在Sprint中去现实地评估事情，比等到Sprint结束后再进行任何变更，要好的多（香不香？）。

查看并澄清即将发布的用户故事

讨论并同意验收标准（Acceptance Criteria），以确认双方的理解。以及确认估算大小和拆分太大的故事

提醒：任何故事，如果团队在一个SPrint内无法完成4个，那么就是太大了。

同意下一个Sprint的计划

根据我们的速度预测和大小确定，这是一个现实的计划吗？

如果对上一个问题的回答为"否”，则拆分故事，或交换优先级相近的小故事，直到团队对计划充满信心为止

注意：另请参阅多年前我写的产品列表梳理

Daily Scrum

定义

每日Scrum（又称每日站会）是开发团队通过简短的、有针对性的对话来确保他们每天保持一致。每日Scrum期间发生的主要事情：

• 分享知识

• 找出帮助其他团队成员的机会

• 识别依赖性、风险

• 同意删除障碍的后续步骤

频率

每天一次（一般SPrint第一天除外，因为已经有了计划会）；每天同一时间、同一地点，会降低复杂度。

持续时间

每日Scrum的持续时间不得超过15分钟。

参与者、输入、输出

参与者 – 开发团队，ScrumMaster（或其他主持人），产品负责人

输入 – 主要输入是自上次"每日Scrum"以来的任何工作。其他潜在的输入包括在测试过程中可能出现的任何异常情况、优先级的更改，或其他可能影响Sprint计划的任何情况

输出 – 团队成员之间在以下方面达成共识，例如何解决已出现的任何障碍，以及如何在接下来的24小时内最有效地合作以将正在进行的工作项移至已完成方面达成共识

注意： 与会者按重要性顺序列出：每日Scrum用于开发团队，因此会议属于团队的。Scrum Master通常作为主持人出现。但是，团队中的不同成员轮流担任主持人也很常见（不一定只有ScrumMaster来主持）。对于产品负责人而言，阐明可能出现的任何与产品相关的问题也可能会有帮助。

活动

“每日站会程序"的示例如下：

• 开始对话

• 浏览任务墙（快速查看工作流程中的位置，该墙可以是物理卡墙，也可以是Jira中的虚拟墙，或两者兼而有之）

• 头条新闻（是否有特别紧急的事情需要讨论？）

• 更新（障碍或其他团队成员想讨论的信息）

• 击掌庆祝（无论是线下的还是线上的……；）

• 站会之后（与停车场同义 – 必要时可以在站会之后进行的跟进对话）。

• 更新任务板（如果在对话期间更新了任何工作项的状态）

注意：另请参阅Scrum会议的输入输出 

Sprint Planning

定义

Sprint计划会议旨在确保对即将开始的Sprint期间团队计划进行的工作有完全的了解。Sprint计划有几个关键方面：

制定和完善迭代目标

根据其相对优先级，讨论、确认要在Sprint中处理的功能（故事）

在某些团队中，可以进行更深入的对话，其中包括任务分解，其中团队可以针对他们计划从事的任何给定故事，来识别需要完成的特定任务

频率

每个迭代一次（即迭代的第一天）

持续时间

假设在Sprint Planning开始之前已经完成了产品列表梳理，那么许多团队都可以在一个小时或更短的时间内完成Sprint Planning。Sprint期间要完成的工作的不确定性越高，Sprint计划花费的时间就越长。

参与者、输入、输出

参与者 – 开发团队，产品负责人，ScrumMaster

输入 – 主要输入是来自 “产品列表梳理” 会议的一组定义明确（清晰、确定、按验收标准划分优先级）的故事。其他可能的输入包括自"产品列表谁"会议以来对优先级的任何更改，或刚刚结束的Sprint中未完成的故事

产出 – 迭代目标和迭代列表（Sprint BAcklog）

活动

从Sprint目标开始

讨论团队正在工作的任何业务或技术假设（这也是确保在产品列表梳理过程中不会丢失任何重要信息的有用方法）

查看自上次产品列表梳理以来可能出现的任何其他新的信息：

对故事优先级的任何更改将在下一步进行

刚结束的Sprint期间未完成的所有故事，可以在即将开始的Sprint期间进行处理，具体取决于它们的优先级

• 检查谁（如果有的话）要休假，以及休多长时间

• 浮现出的任何依赖项或风险，包括谁可能是缓解这些依赖项或风险的所有者，以及预期的影响是什么

• 查看并澄清用户故事：

确认故事的细节和清晰度、以及故事的验收标准和相对大小

（可选）任务分解：某些团队选择在Sprint计划期间，将每个故事进一步分解为一组任务，一些团队单独进行任务分解（在Sprint Planning完成后），而有些团队则根本不执行任务分解（故事比较小的时候不需要拆分任务）

越是新组建的团队，任务分解对他们有帮助的可能性就越大。（分解有助于理解故事的潜在风险）

许多已经合作了一段时间的团队发现没有必要分解任务，特别是当这些团队一致地将故事分解成小块时

• 同意Sprint的计划：

• 如果对前面两个问题的回答为"否”，请寻找在团队成员之间更均匀地分配工作的方法，或说明为解决依赖关系或风险而需要采取的措施

• 基于团队能力，这是一个现实的计划吗？

• 是否已确定所有依赖关系或风险？

• 当团队就计划达成一致时，请确保相应的任务白板（如果团队使用的是物理白板）和Jira同步更新

• 重新审查Sprint目标，并确保它们与团队的Sprint计划相一致  

Sprint Review

定义

Sprint评审会议旨在确保完全清楚地说明团队在Sprint期间完成的工作以及他们接下来将要开展的工作。Sprint评论有几个关键方面：

自上次Sprint评审以来产品中发生了什么变化

当前产品功能的演示（Demo）

团队接下来要进行的工作预览

频率

每个迭代一次（迭代的最后一天，回顾会议之前）

持续时间

由于形式不同，比如单团队Sprint评审或多团队Sprint评审，因此此类会议的时间可能会有很大的不同，从单个团队的30分钟到多个团队的几小时都是可能的。

参与者、输入、输出

参与者 – 产品经理，产品负责人，ScrumMaster，开发团队，利益干系人

输入 – 主要输入是团队在Sprint期间完成的一组工作项。其他输入包括自上次Sprint评审以来对战略或产品级别的总体愿景或优先级的任何更改

产出 – 明确团队完成的工作；利益干系人对团队完成工作的反馈；明确考虑团队的下一步计划，并考虑到所有利益干系人的反馈以及业务重点

活动

当前Sprint完成工作，在整个产品中的位置（总览）

讨论Sprint目标以及团队达到目标的程度

演示团队完成的工作

尽量避免以用户故事x，用户故事y（细节水平可能对某些涉众没有意义）来描述作品

相反，应专注于讲述有关产品当前行为的连贯叙述

确保利益干系人有机会提供反馈

（可选）探讨团队在Sprint期间可能遇到的任何挑战，这些挑战的影响以及团队如何克服这些挑战

认可团队所做的工作（以及在Sprint期间帮助其他团队的每个人）

预览下一个Sprint中即将发生的事情

确保考虑可能影响这些计划的反馈

还可以提供有关团队在下一个Sprint之后将关注的重点的见解；重点是接下来（下一个SPrint）要发生的事情

Sprint Retrospective

定义

Sprint回顾是团队进行公开而诚实的对话的机会，对话通常集中于团队在Sprint中所做的工作。Sprint回顾本质就是团队级别的Kaizen（或持续改进）。

频率

每个迭代一次（迭代的最后一天，最后一个活动）

持续时间

团队的氛围在Sprint回顾的过程中起着重要作用。对于刚起步的团队，或者发现团队需要面对重大挑战的情况，可能需要花最少一个小时的时间。其他时候，则30分钟足够。

参与者、输入、输出

参与者 – ScrumMaster，产品负责人，开发团队

输入 – 主要输入是团队在Sprint期间进行的各种活动

产出 – 明确说明团队工作方式的潜在变化，明确表达为团队同意的可行步骤，可以帮助团队尽可能有效地开展工作

（+）一些敏捷从业者建议，产品负责人没有必要（甚至不希望）参加Sprint回顾。鉴于产品负责人，ScrumMaster和开发团队之间的关系非常重要，因此作为惯例，产品负责人参与回顾会，很可能会帮助该团队。

（++）为了心理安全，只有开发团队，Scrum Master和产品负责人的成员参加Sprint回顾是一种标准做法。

（+++）团队经常在Sprint回顾会议上讨论很多事情。但是，团队在Sprint回顾会议上谈论的内容属于机密信息，不会分享给其他人。另外，团队的改进相关的任何行动步骤，通常对其他人可见。

活动

主持人（通常是ScrumMaster）为对话奠定了基础

如果主持人已经根据自己的具体情况，预先准备了哪些活动和哪种类型的对话，最有可能为团队提供帮助，那么Sprint回顾会议就会是高效的会议。

为了建立心理安全，始终谨记Norm Kerth所阐明的"回顾会议的最高指导原则”：

无论我们发现什么，我们始终理解并坚信，鉴于团队当时所知道的信息、技能、能力和可用的资源以及当前的情况，每个人都已经尽了最大的努力。

在ScrumMaster的帮助下，团队重新思考了刚刚结束的Sprint。要讨论常见的三个方面的问题：

在Sprint期间进展顺利的地方

在Sprint期间进展不顺利的地方

团队可以采取哪些可行措施来持续改进

重要的是永远不要忽视积极的一面。确保包括积极观察的好方法很简单、例如询问"谁愿意感谢另一位团队成员”（或团队外部的人）在Sprint期间提供的帮助？

团队同意的行动步骤，张贴到SPrint Backlog。可视化！

（+）引导回顾会议的方法非常多。每个团队每个SPrint都不一样，因此作为SCrumMaster需要有一个工具箱来引导回顾会。

发邮件索取引导回顾的工具箱 bob@bobjiang.com  

Story Splitting

故事拆分步骤

1. 准备需要进行拆分的故事；除小故事以外，故事是否具有INVEST属性？（请参阅用户故事以进行复习。）是/否

• 如果是，请继续。

• 如果否，请先梳理故事，然后再尝试拆分。请参阅编写清晰明确的用户故事快速入门指南

2. 根据当前大小，故事是否太大且无法在当前Sprint中完成？是/否

• 如果是，则应继续进行拆分

• 如果否，无需进一步。

3. 根据目前的规模（大小），故事是否可能消耗团队的大部分时间？（也就是说，完成一个故事不应消耗该团队迭代能力的大部分）是/否

• 如果是，应将其拆分

• 如果否，则无需进一步

4. 应用拆分模式；在考虑如何拆分故事时，请牢记以下两个准则：

• 选择一种模式，导致多个拆分后的故事可以被取消优先级甚至删除。假设应用一种拆分模式会暴露低价值功能，而另一种则不会。这可能表明使用后一种拆分会在拆分后的故事中隐藏浪费（即低价值的故事）。应用拆分模式应该可以降低工作的优先级或消除工作。

• 选择一种模式，以产生大小相同的拆分后故事。如果拆分后的故事大小相同，则可以使优先级划分更加容易。

拆分模式

这里讨论的拆分模式是：

• 工作流程步骤模式

• 业务规则变化模式

• 简单/复杂模式

• 数据模式的变化

• 数据输入方式

• 操作模式

• 推迟性能模式

• 探针模式

工作流程步骤模式

假设某个特定的故事是基于完整的工作流程。因此，此模式沿工作流中各个步骤将较大的故事拆分开，例如：

• 作为作者，我希望能够提交我的文章，以便将我的内容发布

• 作为编辑，我希望在文章提交后得到通知，以便我及时进行审查。

• 作为编辑，我需要批准一篇文章，以便该文章可以排队发表。

• 作为编辑，我希望能够请求更多信息，以便及时与作者联系。

业务规则变化模式

这种模式试图将特定故事中存在的业务规则分开，以寻找机会根据这些业务规则之间的差异来拆分故事。以下是一些示例业务规则：

• 付款的币种必须于特定地点购买

• 现金付款面额不得超过。。。

• 收款的条形码是使用……设计的

简单/复杂模式

使用简单/复杂模式，寻找机会修改非常笼统的故事（这通常掩盖了复杂性）。尝试为每部分定义验收标准有助于简化此过程。例如，

作为贷款申请者，我想计算抵押贷款付款额，以便可以确定哪种贷款类型适合我

可能会通过诸如……的方式变得更加具体。

…手动计算我的抵押付款

…使用在线电子表格模板计算我的抵押贷款付款

…使用在线计算器计算我的抵押贷款还款额

数据模式的变化

在这种模式下，焦点转移到数据对象上。与团队合作，根据用户角色和操作选择数据对象的选项。假设有称为"产品”，“付款"和"收据"的数据对象。在这种情况下，想法是针对每种对象类型专注于特定的数据类型。因此，对于"产品”，可能会有诸如Book，DVD和Gift Card之类的数据类型。

然后，您可以与产品负责人一起确定具有最高业务价值的数据类型，并据此拆分故事。故事中的复杂性可能来自处理数据的变化。

数据输入方法模式

有时用户界面本身会显示复杂性。在这种情况下，可以用UI的方式来拆分故事，然后再构建更高级的UI。当然，这些不是独立的。如果您先做第二个故事，那么第二个故事实际上就是原始故事。但这仍然是有用的拆分。

作为用户，我可以搜索两个目的地之间的航班，以便选择最适合自己的航班。

可以修改上面的故事，以限定可能需要什么样的用户输入，如下所示：

…使用简单的日期输入来搜索航班。

…使用精美的日历界面搜索航班。

推迟性能模式

在这种模式下，想法是寻找机会推迟使现有故事变得异常庞大的工作。试图通过一个故事来实现特定的性能目标可能会使其变得很大。通常最好将系统性能视为需要更广泛解决的全局条件（例如，作为"完成的定义"的一部分）。

以下是"非功能性"需求的一些其他示例，通常最好分开考虑：

• 国际化/本地化

• 安全

• 可伸缩性

注意：我不是说，上述定义的"完成的订义"注意事项并不重要；我们在这里要避免的是尝试通过单个用户故事解决此类问题。

操作模式

在这种模式下，尝试着眼于操作和过程。一些团队可能从CRUD（增删改查）方案的角度来看待此问题，例如：

作为店主，我要管理在线商店中要出售的产品，以便可以出售人们想要购买的东西。

如果上述故事仍然太大，则可以根据如下CRUD操作将其进一步拆分：

作为店主，我想从我的在线商店中添加和删除产品，以便潜在买家更容易找到产品。

作为店主，我想在我的在线商店中编辑产品详细信息，这样我就可以避免重新创建产品以解决错字问题。

另一个常用的经验法则是注意通用动词，例如"管理”。例如，如果有一个用户故事说"作为一名新学生，我想管理我的帐户…"，“管理"一词往往会掩盖更具体的操作，例如"取消帐户，编辑帐户”，以及以此类推。

探针模式SPike

一个故事可能不是很大，不是因为一定很复杂，而是因为对实现的了解不多（未知领域）。首先执行时间限制（如1-2天），以解决实施过程中的不确定性。然后，您可以执行实现或更好地了解如何分解它。假设您不确定要采用哪种技术方法来实现以下故事：

作为用户，我可以用信用卡付款，因此我的交易可以迅速完成。

您可以先从一个探针（SPike）开始：

Spike：选择一种用于信用卡处理的技术

然后继续执行上面所述的故事（假设故事足够小，不需要先拆分即可。）

在"选择技术"的过程中，验收标准应该是您需要回答的问题。做足够的调查就可以停止；否则很容易迷失方向进行研究。

探针模式是最后一个，因为它应该是最后的选择。您可能知道足够的知识来构建。这样做（探针），您将了解更多。因此，在采用探针模式之前，请尽一切努力使用前面八个模式之一。

评估拆分故事

您需要询问以下几个问题来确定原始故事是否已被拆分，以及拆分后的故事是否需要进一步处理：

1. 拆分后的故事大小是否大致相等？是/否

• 如果否，请考虑采用其他模式拆分原始的故事，或选择一种模式拆分任何大于其他故事的拆分后的故事

2. 每个拆分后的故事都具有所有INVEST属性吗？是/否

• 如果否，请考虑采用其他模式拆分原始故事，或重构任何需要重做的拆分后故事。

3. 拆分后的故事中有没有特别揭示高价值或低价值的部分？是/否

• 如果是，请与产品负责人一起确定拆分后故事中的部分是否：a）相对优先级高于其他拆分后故事；b）必要的（有时通过拆分故事来揭示并非真正必要的工作）

故事属性

在编写用户故事时，请努力确保每个用户故事都满足所有INVEST属性，其中INVEST代表：

• 独立的 Independent

• 可商谈的 Negotiable

• 有价值的 Valuable

• 可估算的 Estimable

• 较小的 Small

• 可测试的 Testable

• 独立的 – 在最大程度上，一个用户故事应该与另一个用户故事无关。这对于同一Sprint中正在处理的故事特别重要，因为故事之间的依赖性会使计划、优先级排序以及估算变得更加困难。尽可能在Sprint中来拆分或修改故事以减少或消除依赖性。

• 可商谈的 – 用户故事是可协商的，因为实际的故事卡（或其电子表示形式）旨在作为与将要构建的团队的"对话邀请”。与故事相关的详细信息在此对话期间得以解决。

• 有价值的 – 每个故事的用词很重要，以使与故事相关的商业价值显而易见。这就是产品负责人在帮助团队了解用户故事的"为什么"和"什么"方面起如此重要作用的原因。与每个故事相关的技术细节（“如何”）可在与该故事相关的描述性细节或单个任务中找到，并且团队根据对"为什么"和"故事"的理解来确定"如何做”

• 可估算的 – 至少故事需要足够清晰，以使团队能够对故事的相对大小进行初步估计。可能会影响团队评估能力的常见问题包括：缺乏领域知识（这就是为什么围绕故事的"对话"如此重要）以及过大的故事（在这种情况下，故事需要拆分为多个小故事）。

• 较小的 – 从最基本的角度讲，故事必须足够小才能在Sprint中完成。根据团队的规模，迭代的时间长短和其他因素，团队通常将故事拆分得足够小，以便至少可以在一个迭代中完成六个（通常更多的）故事。简而言之，较大的故事会给团队带来麻烦，因为较大的故事代表这更多的不确定性，以及思考的深度不够。

• 可测试的 – 如果故事无法测试，则团队几乎不可能（更不用说产品负责人）知道故事何时"完成”。一个经典的反模式是当故事包含诸如"易于使用"之类的不精确的语言时（因为没有直接的方法可以测试易用性）。因此，需要以一种可以容易地从中得出测试方法的方式来编写验收标准。

参考文献

本快速入门指南中的内容基于Richard Lawrence在其博客上观察和编译的模式。这个博客上也有一篇我翻译的中文的拆分模式。  

Writing Great User Stories

团队通常难以编写清楚传达以下内容的用户故事：

• 目标用户（角色或用户类型）

• 目标用户想要达到的目标

• 达到特定目标对用户很重要的原因

• 开发所需功能并测试该功能是否按预期工作的技术方法

注意：常见的误解是，编写用户故事的唯一责任在于产品负责人（或产品负责人的代理人）。尽管大多数情况下是产品负责人起草用户故事，但让团队成员参与编写和完善用户故事这很重要，因为当团队参与此活动时，每个人对什么内容会有相同理解，并且我们也知道为什么要构建以及我们如何知道何时完成。

各个部分介绍了明确表达的用户故事的每个主要组成部分：

• 标题

• 描述

• 顺序

• 大小（规模）

• 验收标准

• 技术方法

故事标题

就像其他类型的标题（又称标题）一样，故事标题应该简短，因为简短的陈述……

• 更容易在物理媒体上书写，例如索引卡或便签纸

• 在查看多个故事时，团队成员更容易口头参考

• 使用诸如Jira之类的工具编写故事时，团队成员更易于解析
  注：故事标题映射到Jira中的"摘要"字段。

故事标题格式

对于故事标题，建议使用以下格式：（角色）（动作）（上下文）

例如：

主申请人输入密码

其中 …（角色）=主要申请人 （操作）=输入密码

注意：（角色）和（动作）是必需的，而（上下文）在标题中是可选的。例如，当有许多标题相似的用户故事时，添加上下文可以帮助区分它们。在上面的示例中，用户可能会在正在构建的应用程序的不同位置输入密码，或者可能存在不止一种密码。在这种情况下，添加上下文可以增加清晰度，例如"主要申请人输入密码（页面类型），或主要申请人输入密码（密码类型）。

故事描述

故事描述的规范格式如下所述。编写故事说明时，请记住以下几点。考虑投入和产出：

• 人或系统输入哪些数据（或其他类型的输入）？

• 该输入会产生什么数据（或其他类型的输出）？我们将如何测试？

• 考虑垂直切片：

• 创造价值的最薄的层面是什么？（纵向拆分）

• 我们该怎么做才能确保我们是纵向拆分的呢？（而不是针对不同的水平层（例如，UI，数据库）使用单独的用户故事）

• 考虑可以传达故事意图的最少单词数：

• “不要让完美成为善良的敌人”（写下来然后继续前进；您以后随时可以更新）

• 稍后您可能会意识到此用户故事不是必需的，或者必须分成较小的部分（更重要的是，不要花太多时间在编写任何用户故事上！）。注意：故事描述映射到Jira中的"描述"字段。

故事描述格式

故事描述的规范格式为

• 作为（角色/用户画像/用户类型）

• 我想要（目标或行动）

• 这样以便（目标/行动的期望结果）

例如：

• 作为主要申请人

• 我想输入从代理人那里收到的密码

• 这样我就可以访问我的福利请求并验证信息

故事顺序

用户故事的优先级由其在产品待办事项列表中的相对位置以及在Sprint待办事项列表中的相对位置反映（最接近列表顶部的用户故事具有最高优先级）。

在列表的待办事项中优先考虑项目的相对优先级不是浪费时间，例如，用户故事的优先级是50还是51。更加重要的是要弄清积压的前10至20个条目。可以节省优先级时间的决策工具称为"金字塔列表”。

注意：” Jira优先级"字段提供了许多其他选项，可以指示任何给定工作条目的相对重要性。本快速入门指南不涉及” Jira Priority"字段的用法。

故事大小

当敏捷团队估算规模时，他们会采用"相对估算”。之所以称为相对估算，是因为我们关注的是事物A相对于事物B的相对大小，或事物B相对于事物C的相对大小，等等。

注意：实际上，选择进行估算的团队通常在进行相对估算时会使用T恤尺寸作为起点。

故事大小格式

对于使用故事点进行估算的团队，最常见的是仅使用斐波那契数列中的数字进行故事点估算：1、2、3、5、8、13…

为什么使用斐波那契数列？

正如花了很多时间来构建软件的任何人所能证明的那样，准确估算我们所构建的任何东西的规模都是一个难题，并且批次的大小（无论是功能还是版本）越大，其不确定性和风险就越大。（因此要保持小批次，有助于降低复杂性和风险。）

使用斐波那契数列已变得很流行，因为这样做可以帮助强化估算永远不准确的观念。例如，当我们考虑将一个用户故事的大小定为3个故事点，并将一个用户故事的大小定为5个故事点时，我们可以肯定地说的就是，基于现在知道，完成5个故事点比完成3个故事点需要做更多的工作。

使用斐波那契数列的另一个吸引人的方面是，数字越大，它们之间的差距越大，这表明随着工作项目变大，不确定性和风险趋于迅速增加。

为什么要估算呢？（“没有估算no estimates”）

精益敏捷社区中的一些从业者建议，花时间进行估算是一种浪费。（特别是在精益管理中，着重于将无法带来业务价值的任何活动减至最小。花时间进行估算，尤其是当团队花过多时间在估算时，该活动就是浪费。）

有些人可能想知道，如果团队不估算列表的工作条目的相对大小，他们将如何预测何时完成特定工作。这些团队的答案通常是简单的：如果需要计算速度，而不是计算故事点，只需计算完成的工作条目的数量。例如，如果一个团队在Sprint 1中完成10个故事，在Sprint 2中完成12个故事，在Sprint 3中完成15个故事，那么他们的速度分别是10，然后是12，然后是15。

注意：在没有估算的情况下取得成功的团队往往也会擅长将工作项分解成相当小的部分，其中最大的部分可能不会花费几天就能完成，一般来讲一个故事1-2天即可完成。本着检视和调整的精神，他们如何估算以及是否估算，可能是团队进行试验的领域。

故事验收标准

对于要视为完成的任何用户故事，都需要满足其验收标准，并且需要与"完成的定义"中存在的所有全局规定保持一致。

完成的定义和验收标准的联系和区别，可以参考之前的博文

阐明验收标准的目的的一种简单方法是：验收标准指导测试策略，使我们能够（通过测试）证明用户的故事已达到预期目的。

注意：验收标准通常不会直接映射到Jira中的特定字段（取决于Jira的配置方式）。

在Jira中纳入验收标准的方法示例包括：

• 将一个文本字段添加到"故事"问题类型（在"项目设置"中），并将其命名为"验收标准”。

• 将验收条件添加到描述字段

故事验收标准格式

有多种编写验收标准的方法。注意：就本快速入门指南而言，我们仅描述验收标准的"测试……“格式。

测试……

以下是以"测试……“格式编写的测试的几个示例：

• AT-1。测试当用户输入错误的旧密码时，他们会收到一条错误消息，指示不正确的密码

• AT-2。测试是否在1小时内三次错误地提交旧密码导致用户从系统中注销

• AT-3。测试订单确认中包含：

• 订单号

• 预计到达日期

• 客户服务电子邮件地址

故事技术方法

与故事标题和故事描述相反，故事标题和故事描述关注于谁，什么以及为什么，而技术方法（与验收标准一起）则关注如何做。

注意：通常，属于技术方法的工件会作为附件，链接或子任务映射到Jira。

故事技术方法格式

由于技术方法可能会因产品而有很大差异，因此很难为技术故事指定特定格式。以下是一些常见的准则：

• 多个故事通常会引用同一工件或一组工件（例如，流程图，数据流程图或序列图）。只要团队了解工件的位置以及工件的内容，就不一定总是需要将这些工件附加到故事中（但是链接通常会有所帮助）。

• 相比之下，线框或实体模型通常是特定于单个故事的工件，因此，将此类工件附加或嵌入到故事中是一种常见的做法（链接到此类工件通常也是可接受的）。

• 一些团队概述了实现故事所需的技术方法，包括一系列步骤。每个步骤通常称为"任务”，弄清楚这些步骤的过程称为"任务分解”。（在Jira中，通常为此目的使用子任务）。

注意：Jira（和许多其他工具）支持输入与任务相关的时间（通常以小时为单位）的实践。许多敏捷从业者认为任务的输入（跟踪小时数）是浪费，更不用说任务持续时间（即"烧掉"时间）了。换句话说，要重点关注的是功能完成，而不是花费时间。