“我不一定同意我所说的一切”
— 马歇尔.麦克卢汉
前言，在本文中，我们将从以下几点了解关于产能规划的话题：
- 什么是产品待办事项梳理
- 为什么我们要在待办事项中梳理故事
- 谁对待办事项梳理负责
- 什么时候团队应该进行待办事项梳理
- 待办事项梳理细节洞见
- 衡量待办事项健康或梳理状态的指标
- 待办事项梳理之后
什么是产品待办事项梳理(Product Backlog Refinement)
为什么我们要在待办事项中进行梳理故事？
产品待办事项梳理有很多优点，下面列出了其中的几个。
- 通过消除用户故事的不确定性和未知事实来提高效率。
- 提前识别依赖性（在团队和跨职能部门内）和风险，以制定相应的计划。
- 更好的估算并避免返工（开发，测试和实施）。
- 使开发人员和测试人员了解其要求，从而节省了开发团队在sprint周期中进行进一步讨论的时间。
- 确保故事遵循INVEST原则，提供更易于理解的成熟的用户故事
- 有效的Sprint计划：如果在进行Sprint计划前，故事已经进行了梳理和优先处理，PO和开发团队不需要花费大量时间梳理或估算故事。
- 强调最高优先级以挑选故事进行梳理，计划等。
- 给产品负责人提供多次机会，根据实际需要提供更多信息来细化需求。
- 在梳理过程中，如果开发团队遇到一些疑问或问题，并且需要更多时间与PO进行协作，则团队可以将梳理会议中的故事搁置下来，以便PO可以获得更多的信息来补充给故事，并将故事包含在后续梳理会议中。
- 更好地管理产品目标，Sprint目标和里程碑会议。
谁对待办事项梳理负责?
团队成员在产品待办事项梳理过程中的角色和责任。
Scrum团队有三个主要角色，即产品负责人，Scrum Master和包括质量保证在内的开发团队。 每个Scrum团队成员都会参加梳理会议，此外，团队可选择性邀请跨职能团队成员（如DBA，UX / UI，技术主题专家等）参加，为梳理会议补充更多有价值的细节。
下面提到的是团队成员在梳理会议中的主要角色和职责。
产品负责人
梳理前
- 创建用户故事（有时与团队合作），注意INVEST和DoR(Definition of Ready)
- 优先安排待办事项，以便团队可以按优先顺序梳理故事。
- 逐一解释用户故事的需求，有关其验收标准，业务逻辑等。
梳理过程中
- 澄清开发团队，测试人员或任何跨职能团队成员的疑问。
- 将大故事拆分为小故事，注意INVEST。
- 在团队确定故事点后更新故事点。
- 如果故事被认为为完成梳理并符合DoR，就更新故事状态。
Scrum Master
梳理前
- 安排和组织活动或会议
- 与产品负责人进行协调，以确定潜在的高优先故事要进行梳理，并通知开发团队进行相应的准备。
梳理过程中
- 引导产品待办事项梳理会议。
- 确保只是为了梳理的时间盒和最有效的利用时间。
- 引导用户故事的估算。
- 在宣布一个故事完成梳理之前，要确保故事的DoR和INVEST已经满足。
- 记录必要的会议纪要或报告的详细信息。
- 如果故事太大并且可以分解，则引导相关工作。
- 如果需要进一步澄清，请保留该故事以进行梳理。
梳理后
- 向所有相关各方发送会议记录，并提供故事列表和故事点信息。
- 发送项目待办事项健康报告。
开发团队
梳理前
- 全面了解要梳理的故事并进行相应的准备。
梳理过程中
- 理解需求。
- 澄清疑问。
- 参与完善故事的描述和验收标准。
- 识别依赖关系（如果有）。
- 识别风险（如果有）。
- 参与故事点估算。
其他人员
梳理前
- 全面了解要梳理的故事并相应的准备从团队外部给予支持。
梳理过程中
- 理解需求。
- 澄清疑问。
- 为团队提供关于跨职能依赖和复杂性的更多信息。
什么时候团队应该进行待办事项梳理？
理论上，第一次的Backlog梳理的时间是从 Sprint 0中的某个时间开始的。每次梳理都在Sprint n 尚未完成的时候，大多为Sprint中期发生，为 Sprint n 以后的2次迭代准备充分的PBI，才能保证待办事项的健康Backlog Health。
具体需要多少时间要根据团队PBR的效率计算。建议是5%-10%。在主要的高优先级的PBI还比较大的时候，团队可以投入更多的时间在PBR工作上。
这里没有确定何时进行梳理会议。 它不是任何Sprint或发布的一部分。 梳理是每个团队需要进行的一项持续活动，以使产品待办事项保持健康和可持续的发展。 每个团队每周可以梳理一次，两次甚至更多次。 每次会议可以有1到2个小时。 这完全取决于团队针对每个故事进行详细的分析和讨论的速率。
下面是一种可能有帮助的计算方法，以判断应该多久安排一次或计划一下梳理活动。
目标：计划并执行待办事项梳理，准备好是平均速率的两倍故事点的PBI。
示例：如果速率为30个故事点SP，则待办事项中应包含60个SP的完成梳理的故事（这里表示还没被纳入Sprint的故事）
- 计算“速率”作为最后6个Sprint的平均值。
- Sprint持续时间为2周。
- Scrum Master记录了每个梳理会议的时间和梳理的故事点。
根据计算，计划每周至少两次，每次45分钟；或每周一次，每次1小时30分钟。
注意 ：
- 如果积压中已经有一些梳理过故事，需要相应地进行计算。
- 在每次Sprint计划后，因为团队将梳理过的故事提交到Sprint。从而待办事项健康度降低。
- 应该安排比计算的时间更多的时间，以应对如果有大量优先的待办事项。
- 一份产品待办事项和多个团队
- 不要提前过多度梳理，因为，情况变化可能会使梳理后的故事失去原来的优先顺序，从而导致浪费时间。
为什么团队不应该在Sprint计划中安排待办事项梳理
团队在梳理过程中多次遇到以下挑战：
- 根据DoR的定义，有少量故事可能尚未就绪。
- 有少量故事需要更多的信息，才能就绪。
- 产品负责人需要一些时间来澄清开发人员/测试人员提出的一些疑问。
- 识别出的依赖项需要跨职能团队的认同才能提交到当前的Sprint，没有足够的时间获得反馈。
- 产能使用效率低，提交的故事数少于团队能够做到的，从而降低了速率。
- 在Sprint期间中引入新故事来提供给可用的产能，从而留下范围蔓延的机会。
- 引入了一种不必要的技术实践，对组织没有任何价值。
由于这些挑战，团队通常会跳过在Sprint计划中梳理的故事，并将其安排在下一次梳理中。如果团队把带着这些未解决的问题的故事提交到当前的Sprint，那么
- 团队实际上正在将承诺置于风险中，并且很有可能打击未来承诺的可靠性。
- 开发具有不确定性的需求，导致在生产/ UAT或测试环境中出现错误。
待办事项梳理的细节见解
做产品待办事项梳理的团队需要什么？
澄清需求：
弄清需求是梳理用户故事的最重要目标。 所有开发团队成员都必须参加这个活动，并了解用户故事的要求，产品负责人或业务用户对该故事的期望。 他们讨论需求，澄清疑问（如有），分析风险和依赖性等。
如果用户故事需要跨职能团队的参与，则Scrum Master可以引导外部团队成员的参与和出席，从而使开发团队可以清楚地了解需求。 这样他们就可以按照期望以最优化的时间进行开发和测试，而不会出现故障和错误。
如果仍然有任何疑问或问题，请团队将故事搁置，可以在将来进行梳理活动，责任人可以做相关功课，并在下次澄清所有疑问。 然后，团队从待办事项中选择下一个优先级最高的故事，并开始进行梳理。
查看每个故事的以下方面：
原则-INVEST
SM和PO组成的团队检查故事的特征。 如果不匹配INVEST，请尝试进行更改/在用户故事中添加内容或将其分解为较小的用户故事等。INVEST是好的用户故事特点的缩写
Independent – Negotiable – Valuable – Estimable – Small – Testable.
结构-3C
团队检查用户故事的结构。好的用户故事应包含三个部分：
Card – Conversation – Confirmation.
分解大故事为小故事：
团队需要分解大的故事，使每个故事都能小于Sprint产能，并可在2-5天内处于潜在交付状态，注意每个故事都应遵循INVEST。很多时候，用户故事太大而难以估计或放入一个Sprint或捕获故事中的细节，或者出于许多其他原因，团队应该尝试将用户故事分解，以便于管理，跟踪和执行。
验收标准：
用户故事必须有验收标准。 这些是测试人员用来验证开发的标准。开发团队和测试人员必须了解验收标准，并找出其可行性，依赖性，并澄清疑虑。技术/领域专家的可以在需要时提供他们的意见。
估算故事点：
团队应在梳理会议中估算故事点。 仅估算故事点，而不估算任务时间或工作量。
校验"准备就绪定义" DoR
团队维护就绪的定义，包含一个检查列表。以后会写个关于DoR的主题。以下是DoR中的举例
1.故事应该有标题
2.故事应该有一个接受标准
3.故事应该有一个估算的故事点
4.其它
团队在声明故事已梳理之前，验证故事是否符合DoR定义下的所有检查项。
更改故事的状态：
最后，一旦所有团队成员都同意故事梳理完毕，SM或PO就可以更改其状态将故事标记为已梳理。 所有用户故事都有4至5个不同的阶段，也可以根据需要自定义工作流程。最终目标是以某种方式标记故事，以便您可以轻松过滤掉所有已梳理/未梳理的故事，并在各种报告和指标上使用这个状态。
衡量待办事项健康度或梳理状态的指标
梳理不需要太多的指标。团队可以分析梳理的实践并确定目标，从而增加待办事项健康度和梳理的效率。下面说明了两个指标，它们可以帮助团队实现更好的待办事项健康度和梳理效率。
待办事项健康度(Backlog Health)
假设组织待办事项健康的标准是任何时候都有可供2个未来Sprint使用的梳理过的用户故事。可以通过速度（此处的速率是最后5个冲刺平均值）乘以2来计算得出。从下面的示例中得出：当前速度为32。因此，要想拥有一个良好的待办事项，至少应有64个故事点梳理并准备进行计划。根据该示例，待办事项中梳理过的只有40个故事点。 因此，待办事项的健康度为62.50％。
梳理效率
计算和衡量团队的梳理效率。 Scrum Master或任何一人需要维护每次梳理会议的记录，包括日期，梳理的故事点数以及该会议花费的时间。 该记录将提供每个会议梳理的故事点的趋势以及基于平均值的梳理效率。 以下示例说明了如何通过平均最近10次梳理会议来计算趋势和效率。 它还可以帮助团队计划将来的梳理，以计算达到100％待办事项健康度所需的梳理时间。
待办事项梳理之后
梳理完之后，团队可以进行一些活动，如下所述：
Scrum Master可以将梳理会话的摘要发送给团队和相关方。
样本格式可能是这样的：
团队<团队名称>梳理说明
日期/时间：<日期> / <时间>
持续时间：<时长（小时）>
参加者：<参加的队员名单>
已梳理的总故事数：<已梳理的故事数>
已梳理的故事点总数：<已梳理的故事点总数>
尝试和跳过的故事总数：<由于没有任何完整的数据或信息，已讨论但未梳理的故事数，并留给下一次梳理的故事>
已安排下一次梳理：<已安排下一次梳理的日期和时间>。
完成梳理的故事摘要
| Story ID | Story Title | Story Point |
| 1 | <Story 1 Title> | 2 |
| 2 | <Story 2 Title> | 5 |
| 4 | <Story 4 Title> | 5 |
| 5 | <Story 5 Title> | 2 |
| 7 | <Story 7 Title> | 3 |
| 8 | <Story 8 Title> | 8 |
| 9 | <Story 9 Title> | 2 |
| 10 | <Story 10 Title> | 2 |
| Total | 29 | |
未完成梳理的故事摘要
| Story ID | Story Title | Reason for not able to groom |
| 3 | <Story 3 Title> | Mention Reason |
| 6 | <Story 6 Title> | Mention Reason |
由于数据或信息不完整，团队需要处理被搁置的故事
Scrum Master，产品负责人和开发团队可以在故事中收集所需的信息，或者通报给跨职能团队成员，在计划的下一个梳理会议上团队可能需要他们的共同参与等。
—
END
希望能在评论区学习到大家的经验和想法~
如果对相关内容感兴趣可以关注我的公众号：捷伴行Agile。会有更多更及时的内容与君分享。
