如何将你的改进细化为可操作的快速技巧?
“下一个Sprint，我们将更早更频繁地发布游戏。”
“从现在开始，我们将改进与利益相关者的合作方式”
“让我们扩展完成的定义以提高质量”
“为了最大限度地减少依赖，我们将努力成为一个跨职能的团队”
“让我们尝试使用产品目标和冲刺目标来让我们的团队更加专注”
这是Scrum团队所做的五个常见改进的例子。我在与Scrum团队的工作中亲身经历的改进，或者在我们的培训、研讨会和聚会中听到的改进。这些改进的意图是伟大的，是有意义的。我只能鼓励球队在这些方面有所改进。
只有一个问题。有了这样的改进，它可能只会保持良好的意图。它们太模糊、抽象或全面了。目前还不清楚谁将做什么、何时、为什么或如何做。即使这一点很清楚，改进还是太大了，无法完成下一个Sprint，这使得你很难确定你是否在朝着正确的方向前进。因此，Scrum团队很难启动他们的引擎来持续改进。Scrum团队没有经历“透明、检查和适应”的过程，无法适应，因为这些改进是不可行的。
发生这种情况的原因之一是Scrum团队确实细化了他们的产品待办事项列表，但他们没有细化他们的改进。这是令人惊讶的，因为改进也应该被视为“工作”。作为产品和Sprint Backlog的一部分的工作。
在这篇博文中，我们将解释产品待办事项列表细化的目的，并分享如何细化改进的示例。我们还展示了(免费)Scrum团队调查包含精炼的快速技巧，以支持Scrum团队的持续改进。如果您的团队难以确定小而具体的改进，不妨尝试一下!
许多Scrum团队没有经历“透明、检查和适应”的过程，而是无法适应，因为这些改进是不可行的。它们太模糊、太大或太抽象，无法实现。
产品待办事项列表细化
正如我们在Scrum纸产品待办事项列表细化的存在，首先是将大块的工作分解成较小的工作块。与Scrum框架中的所有东西一样，这使得经验工作更容易。如果我们要处理大型项目——需要几周甚至几个月才能完成端到端的工作——我们将无法从实际涉众那里得到频繁的反馈。这引入了一个重大的风险，即我们对涉众需要什么做出了不正确的假设，一旦被证伪，就需要我们回过头来改变一切。
因此，我们Scrum的目标是更频繁地交付更小的工作块，这样我们的涉众就可以给我们有意义的反馈，激发新的想法，对已经完成的工作进行更改，或者发现需要解决的bug。简而言之，交付小块的工作是帮助我们思考和理解需要什么的好方法。
你的产品待办事项列表中的所有工作最终都应该细化到足够小——但只有当你即将在即将到来的Sprint中开始工作时。什么东西“足够小”很大程度上取决于你的上下文。但是作为起点，你的团队应该完善到他们能够在一个Sprint中轻松地选择和完成多个项目的程度。有经验的Scrum团队会告诉你，通常越小越好。
产品待办事项列表细化是为了将大块的工作分解成较小的工作块。这是帮助团队理解需要什么，并尽早和经常验证假设的好方法。
出于完全相同的原因，Scrum团队应该将他们的改进细化成小块的工作。因此，他们可以验证改进是否具有预期的影响，以及是否有必要进行更改。它避免了在一个大的改进上花费几周甚至几个月的时间，最后却发现根本解决不了问题的风险。这不仅浪费时间和金钱，还会损害团队士气。
Scrum团队调查有什么帮助
与Scrum团队调查，团队可以通过广泛的、经过科学验证的调查进行自我诊断，并在完成调查后收到详细的结果和基于证据的反馈。一些反馈包括建议自己动手的研讨会和可以尝试的快速技巧。的65个DIY工作坊允许Scrum团队创建Scrum状态的透明度，提供一步一步的解释，一起检查结果，并提供相应的调整指导。
然而，仍然有可能出现团队规模太大的情况。这就是为什么我们也创造了基于“解放结构”的快速技巧15%的解决方案加雷斯·摩根定义了这些作为你可以采取的任何第一步，不需要别人的批准或资源，这完全在你的自由裁量权范围内。如果你想，你现在就可以开始。这可能不是最终的解决方案，但绝对是朝着正确方向迈出的良好的第一步。
从小事做起，引发大的改变。15%的解决方案”。在Scrum团队调查中，我们称这些为“快速提示”。
以下是三个快速提示:
- 提高心理安全的小窍门:在下一次Sprint回顾中，问自己:“作为一个团队，我们目前没有进行，但确实应该进行的对话是什么?”接下来，进行对话!
- 提高自我管理的小技巧:在你目前的工作方法中，挑出一个阻碍你作为一个团队前进的方面。不要为了冲刺而做这件事。在Sprint回顾期间反思哪些改进了，哪些变差了。
- 提高管理支持的快速技巧:在你的下一次每日Scrum之后花10分钟，问自己“我们如何判断管理层是否在正确的领域支持我们?”还需要什么?”共同努力找出改进。
这些快速提示的目的是在您的Scrum团队中引发微小的增量变化。在正确的方向上迈出一小步，以消除障碍，改善协作，管理风险，并更快地交付价值。
如何创建自己的快速提示?
一个好的快速技巧是简短而简洁，可操作而具体，大胆而勇敢，易于使用和尝试。现在让我们再来看看我在这篇博客文章开始时分享的5个改进。让我们来看看如何改进它们，以满足所有的标准!
示例1:
“下一个Sprint，我们将更早更频繁地发布游戏。”
更精细的改进是:
- “让你的支持组织中至少有两个人参与进来，以确定并消除一个瓶颈，以便在下一个Sprint结束时在你的团队中释放自动化。”
- “拜访一个已经自动化了一些你还没有自动化的东西的团队，并从他们那里获得一个你也将在下一个Sprint中实现的想法。”
- “保证在这个Sprint中至少发布2次。将此视为激发创造力的约束。在你开始制作一款游戏之前，先考虑如何单独发行它。”
示例2:
“从现在开始，我们将改进与利益相关者的合作方式”
更精细的改进是:
- “与你的产品负责人合作，为下一个Sprint安排至少2次与利益相关者的面谈。对你团队中的1 - 2名成员和产品负责人进行面试。”
- “下一个Sprint，去你的产品有很多用户的地方实地考察。你也可以分开访问多个网站。互相汇报你们的发现。”
- “在您的团队空间中创建一个(虚拟)办公桌，并邀请您的利益相关者之一在即将到来的Sprint中使用它。”
示例3:
“为了最大限度地减少依赖，我们将努力成为一个跨职能的团队”
更精细的改进是:
- 在下一个Sprint中，让每个人至少完成一项他们从未做过的任务。事后分享经验。”
- “在Sprint回顾期间，确定至少3个团队成员将在下一个Sprint中改进的1个几乎不可用的技能。”
- “在下一个Sprint中组织一个研讨会，让擅长某项特定任务的团队成员演示他们如何完成任务，并帮助其他人也完成任务。”
示例4:
“让我们扩展到完成的定义以提高质量”
更精细的改进是:
- “在你的下一个Sprint中，与5个利益相关者分享你的完成定义。问问他们，他们认为你应该增加什么具体的测试或检查来提高质量。”
- “调查最近sprint中发生的3个关键错误，并共同努力确定前进的一小步，以防止将来出现类似的错误。根据需要更新你的完成定义和工作协议。”
- “在下一个Sprint计划一个60分钟的研讨会，以确保你的“完成定义”捕捉到高质量对你来说意味着什么。任何关心这件事的人都可以参加。”
例5:
“让我们尝试使用产品目标和冲刺目标来让我们的团队更加专注”
更精细的改进是:
- “作为一个实验，以一个你想要实现的单一目标开始你的下一个Sprint，然后从产品待办事项列表中选择符合这个目标的项目。”
- “下一个Sprint，你的团队会礼貌地对任何不符合Sprint目标的非关键请求说‘不’。”
- “问问你最重要的利益相关者，他们认为你下一个Sprint的目标应该是什么。如果太宽，就把它缩小一点。”
你发现这些快速的技巧有什么共同点了吗?所有这些改进都是小而具体的，可以在一个Sprint中完成。谁做什么，什么时候做，怎么做都很清楚。它们不是所有问题的最终解决方案，但它们会鼓励团队不断地进行小的改进。朝着正确的方向迈出一小步。他们将允许团队了解需要什么，确定接下来的步骤，并通过显示更改是可能的来简单地提高团队士气!
为了支持Scrum团队创建和获取这些改进，我们在Scrum团队调查中包含了“行动页面”。添加一个动作需要完成的字段已经帮助团队做出具体的动作。团队还可以将改进行动标记为“障碍”，表明他们需要其他人的支持才能完成这项工作。因此，持续改进成为团队的共同责任而且支持机构。
Scrum团队调查为团队提供了捕捉改进行动的机会。添加操作时需要完成的字段已经帮助团队使其具体化。
关闭
产品待办事项列表细化是许多Scrum团队的共同活动。不知何故，改进的细化不是。这是令人惊讶的，因为改进也应该被视为“工作”。作为产品和Sprint Backlog的一部分的工作。太大、太模糊或太抽象的改进很难实现。因此，团队努力消除障碍并进行必要的改进。这会影响团队士气，形成恶性循环。在这篇博文中，我们向你展示了一种可操作的快速技巧。在下一次Sprint回顾时尝试一下吧。确定一个改进，并一起努力使它尽可能小、具体和可操作!
产品工具包:在您的组织中释放Scrum．这个新的产品工具包包含了102个快速技巧来提高你的Scrum团队。我们将它们分类为你在Scrum团队调查中也能找到的因素。