Scrum——细化产品Backlog是Scrum团队的职责
阅读时间:9分钟
在“Scrum from the Trenches”系列博客文章中,我喜欢讨论我在现实世界中与真正的Scrum团队一起实践Scrum时遇到的主题。分享理论如何应用于实践,团队在过程中遇到了什么挑战,以及如何帮助Scrum实践者使用经验主义的力量来克服这些挑战。
产品待办事项列表细化
在之前的“来自战壕的Scrum”博客中,我谈到了冲刺目标.中多次提到了冲刺目标Scrum指南在Scrum指南中,产品待办事项列表的细化只被提到了几次,甚至更没有规定。没有什么(更多)关于估计和如何排序。没有更多关于“10%”的词了。唯一提到的是:
- 在冲刺阶段:“产品待办事项列表是精制根据需要”
- Sprint计划的主题二:“通过与产品负责人的讨论,开发人员从产品待办事项列表中选择要包含在当前Sprint中的项目。Scrum团队可能完善这些项目在这个过程中,增加了理解和信心。”
- “产品待办事项列表细化是将产品待办事项列表项分解并进一步定义为更小更精确的项的行为。这是添加详细信息(如描述、顺序和大小)的持续活动。属性通常随着工作领域的不同而不同。”
在本文中,我将为您提供一些指导和实践。Scrum指南(故意)没有告诉你如何改进你的产品,因为有很多实践可以这样做。Scrum是一个框架,因此在目的上是不完整的。
定义
Scrum指南中这个定义的第一句话可以看作是产品Backlog细化的定义:
产品待办事项列表细化是将产品待办事项列表项分解并进一步定义为更小更精确的项的行为。
虽然解释是有限的,但很明显,产品待办事项列表细化是与产品待办事项列表项相关的所有活动的总结。因此,产品待办事项列表细化不是一个有时间限制的Scrum事件。因为所有有时间限制的Scrum事件在Scrum框架中都有特定的顺序,产品Backlog细化则没有。在这些限制条件下无法捕获它。更重要的是,将其限制在一个有时间限制的事件中不会使该活动有效。这个约束是很多与我共事的Scrum团队所纠结的:“细化会议”。
“改进会议”
通常,Scrum团队在每个Sprint中聚集一次,或者每周召开一次“改进会议”。产品负责人分享需要改进的产品待办事项列表项(PBI),并由整个团队讨论。在讨论之后(这可能会花费很长时间,而且通常只涉及到很少的人),就会抽出计划扑克牌来对PBI(产品待办事项项)进行评估。
在不谴责这些类型的会议作为一个整体的情况下(它们可以是健康的细化实践的一部分),它们不是Scrum框架事件的一部分,并且经常会有一些功能障碍在这里发挥作用,导致无效的结果:
- 产品负责人在会议中发挥领导作用,将细化的所有权转移到他们自己身上;
- 无休止的讨论,并没有真正获得更多关于这个话题的知识;
- 讨论只涉及几个(高级)开发人员;
- 作出的决定没有记录下来以备将来参考;
- 关于努力的讨论通常是因为努力必须给予PBI,而不是因为获得更多的见解。
- ...等等……
同样,默认情况下,这可能不是一个功能失调的会议。团队经常需要聚集在一起分享见解并讨论工作,以便能够经验地发现可以处理的工作。但这是我经常遇到的事情。
第一步是认识到产品Backlog细化不是一个会议,而是一系列不同的活动。会议可以包括在内。
Scrum团队的每个成员都负责产品待办事项列表的细化:
- 产品负责人:构建正确的东西;
- 开发者:正确构建事物;
- Scrum Master:在这些活动中确保反馈和经验。
让我们从不同Scrum角色的角度来看不同的活动,这些活动可能有助于细化。
产品负责人
如果你是一个致力于产品的产品负责人,细化就从对这个产品有一个愿景开始。首先从产品的“为什么”开始。确保你对这个愿景是透明的,一直与团队和所有利益相关者谈论它。
作为产品负责人,你对产品待办事项列表有权威和责任。每个影响产品待办事项列表状态的活动都可以被视为细化。从产品开发的最早期阶段,设定愿景、策略和产品的预期影响,到开发团队在Sprint计划中评估可以为Sprint选择的产品待办事项项。
下面是一些可以用于产品待办事项列表细化的活动的例子(并不详尽)。它们都是可选的,但都很有用。在这些例子中,由产品负责人发起这些活动是有道理的,但通常其他Scrum团队成员也会参与其中:
- 建立产品愿景;
- 创建产品路线图;
- 制作故事板;
- 为产品创建角色;
- 定义可以验证的假设(即使用开发者的MVP);
- 确定接受标准或满意标准;
- 组织用户故事写作研讨会(与客户和利益相关者一起!);
- 与客户和利益相关者谈论他们对产品的使用;
- 做市场调查;
- 设定目标去实现。
开发人员
我经常遇到开发人员抱怨产品待办事项列表项中存储的信息。他们会说:“信息太少了,无法对此进行研究!”,或者……“这个PBI里有这么多信息,我看不懂!”
关于这样的引用有很多可说的,但也许你认识到这种行为。很多这种行为都与开发人员没有感觉到产品Backlog细化活动的所有权有关。
在我经常遇到的这些具体案例中,我解释说,不同的人对信息的需求是不同的。不仅在角色之间,而且在具有相同角色的人之间(即开发人员)。我告诉他们这很正常,很容易解决。
如果你掌握的信息太少,可以按照你想要的方式获取并记录你需要的信息。但也要确保它对其他人来说是可以理解和可用的。
如果有太多的信息,解决方法也是一样的:与记录信息的人交谈,找出需要什么或可能需要调整的地方。
这里的关键是,产品负责人不是唯一负责细化产品待办事项列表的人。
以下是开发人员主要负责的产品Backlog细化活动的例子(不是详尽的):
- 在Sprint过程中,寻找创造性的解决方案来实现Sprint目标;
- 评估,所以有一个关于Sprint中可以完成的工作的想法;
- 与其他开发人员(也可能是其他团队)讨论和合作,以建立健全的架构指南;
- 做一些小实验/ MVP来验证假设和测试假设;
- 记录下Sprint中可能的解决方案;
- 为产品建立衡量标准,以衡量顾客的行为;
- 将大的PBI分割成更小的功能工作单元。
Scrum管理员
Scrum Master在产品待办事项列表细化中面临的最大挑战是确保每个人都理解细化的挑战。最重要的第一步是在所有层次上建立透明度,并在需要的地方进行教学。在开发人员想要获得更多信息的例子中,除了在现场进行一对一的聊天之外,还可以组织一个关于产品待办事项列表细化的小型研讨会,以解释每个人的角色并确保理解共同的责任。
此外,Scrum Master还可以帮助简化本文中提到的各种活动,帮助每个人专注于自己的角色。
以下是Scrum Master主要负责的产品Backlog细化活动的示例(并非详尽):
- 促进产品待办事项列表细化研讨会;
- 促进价值和工作量评估讲习班;
- 教导在产品待办事项列表细化中分担责任的重要性;
- 教授能够帮助Scrum团队提高其交付和协作方式的透明度的度量标准,即交货时间、周期时间、流程、学习时间、上市时间等;
- 教授和指导产品负责人和开发人员使用自组织(反)模式,就像前面给出的例子一样;
- 帮助开发人员以各种方式分割PBI,同时仍然能够在Sprint中交付“完成”增量。
关闭
这篇关于产品待办事项列表细化的文章表明细化不仅仅是整个Scrum团队进行讨论的会议。它要求每个人都有共同和特殊的责任。因为专注于Sprint,所以很容易忽略产品待办事项列表细化的重要性。但是,为健康的产品待办事项列表优化腾出时间,可以为出色的协作和团队工作让路,从而构建出客户真正喜欢的产品!