scrum流程 规划 冲刺_在开始之前识别出灾难性的Scrum冲刺

scrum流程 规划 冲刺

The best way to recognize a disastrous sprint before it starts is by looking at the sprint goals. A successful sprint depends on many factors, but there are telltale signs that a sprint has a high risk of failure. Let’s start with an example of a problematic set of sprint goals and dissect why they increase the chance of not completing the sprint goals.

在开始之前，识别灾难性冲刺的最好方法是查看冲刺目标。 冲刺成功取决于很多因素，但有迹象表明，冲刺有很高的失败风险。 让我们从一个有问题的冲刺目标示例开始，并剖析为什么它们会增加未完成冲刺目标的机会。

Sprint 1Length 4 weeksSprint Goals:* Create the product view [Sal]* Create the shopping cart [Jill]* Create the checkout [Jack, Bob]* Create seller product management view [Mina, Alice]* Create the user accounts [Alice]* Fix bugs for release [Bob, Jack, Jill, Sal]* Setup database [Daniel, Jill]

Sprint 1长度4周Sprint目标： *创建产品视图[Sal] *创建购物车[Jill] *创建结帐[Jack，Bob] *创建卖方产品管理视图[Mina，Alice] *创建用户帐户[Alice] *修复了发行版[Bob，Jack，Jill，Sal]的错误*设置数据库[Daniel，Jill]

The first problem is the number of sprint goals is equal to the number of members on the team. If the team has seven members and there are seven sprint goals, it’s more complex to keep track of all the progress toward the goals and has a higher chance of falling into a scrum antipattern. The worst-case scenario is all seven sprint goals are worked on in parallel and each team member is working individually on their own piece. Alice doesn’t talk to Sal because their goals don’t relate and Bob is siloed as he is only fixing bugs. Another problem is there may be complex dependencies between goals. The checkout has dependencies on the shopping cart and user account. Shopping cart has dependencies on the product view. I recommend keeping the sprint goals between one to three goals so the team can focus and help each other. Adjusting the sprint length lower can help keep the number of sprint goals smaller.

第一个问题是冲刺目标的数量等于团队中成员的数量。 如果团队有七个成员并且有七个冲刺目标，则跟踪实现目标的所有进度会更加复杂，并且陷入混乱反模式的可能性更高。 最坏的情况是，所有七个冲刺目标都是并行进行的，每个团队成员都是各自为战。 爱丽丝之所以不会与萨尔交谈，是因为他们的目标无关，而鲍勃却因为只修复错误而感到孤立。 另一个问题是目标之间可能存在复杂的依存关系。 结帐依赖于购物车和用户帐户。 购物车依赖于产品视图。 我建议将sprint目标保持在1-3个目标之间，以便团队可以集中精力并互相帮助。 将冲刺长度调整得越低，可以帮助减少冲刺目标的数量。

In combination with the above number of goals problem, the sprint goals should never be assigned to individuals as they are team goals. In my opinion, it’s okay for senior developers to help lead efforts, but going too far is assigning everyone on the team to different sprint goals. Two scrum antipatterns appear as the team has lost its ability to self-organize, and the scrum master has become a project manager. My recommendation is not to assign sprint goals to individuals and let the team figure how to achieve the sprint goals by themselves.

结合以上目标数量问题，不应将冲刺目标分配给个人，因为他们是团队目标。 在我看来，高级开发人员可以帮助领导努力是可以的，但是太过分了就是将团队中的每个人分配给不同的冲刺目标。 由于团队失去了自我组织的能力，出现了两种Scrum反模式，Scrum主管已经成为项目经理。 我的建议是不要将冲刺目标分配给个人，而应让团队自己确定如何实现冲刺目标。

Monolithic goals should never be sprint goals. The “Create the user accounts” goal may encompass large pieces such as registration, login, account management, administrator management, and third party account integration. This example is more of an epic than a sprint goal as epics are usually larger than one sprint. A common problem I have seen with broad sprint goals is new sprints repeating the same goal, or extending the current sprint length to finish. This issue should be brought up in the sprint retrospective for the team to recognize the sprint goal isn’t achievable, and suggest a smaller goal next time. A new team may miss sprint goals in the beginning, but the team should get better over time.

整体目标绝不应是冲刺目标。 “创建用户帐户”目标可能包含较大的部分，例如注册，登录，帐户管理，管理员管理和第三方帐户集成。 此示例更多地是史诗而非冲刺目标，因为史诗通常大于一个冲刺。 我在广泛的sprint目标中看到的一个常见问题是重复相同目标的新sprint，或将当前sprint的长度延长到完成。 应该在sprint回顾中提出这个问题，以使团队认识到sprint目标是无法实现的，并在下次提出较小的目标时提出建议。 新的团队可能在开始时就错过了冲刺目标，但随着时间的推移，团队会变得更好。

Unquantifiable or ambiguous goals are challenging to accomplish because there is a risk of the goal post moving. An unfortunate sprint goal example is “Fix bugs for the release.” At first glance, it makes sense to fix bugs found before a release. However, the problem is as time moves on that the team may need to fix more newly discovered bugs. A definition of done or a better quantifiable sprint goal is the best way to fix the issue. Decide upon a set of bugs to settle in the sprint and list it as the DoD.

无法量化或模棱两可的目标很难实现，因为存在目标移动的风险。 不幸的sprint目标示例是“修复发行版的错误”。 乍一看，修复发布之前发现的错误是有意义的。 但是，问题在于随着时间的流逝，团队可能需要修复更多新发现的错误。 定义已完成的任务或更好地量化冲刺目标是解决问题的最佳方法。 确定一组错误以解决冲刺，并将其列为国防部。

The last and worst problem I have seen is one person is creating all the sprint goals, and the team agrees to it. That’s not scrum because there isn’t a project manager to decide what the team accomplishes for the sprint. The entire team needs to decide on the sprint goals together because they are the ones working toward the goals. One of the best ways to achieve this is to ask everyone on the team what they think can be accomplished and reconcile the opinions.

我看到的最后一个也是最糟糕的问题是，一个人正在制定所有的sprint目标，团队对此表示同意。 这不是混乱，因为没有项目经理来决定团队为冲刺完成的任务。 整个团队需要共同确定冲刺目标，因为它们是朝着目标而努力的目标。 实现此目标的最佳方法之一是询问团队中的每个人他们认为可以达成的目标并调和观点。

Here’s a short overview of what was covered:

以下是所涵盖内容的简短概述：

• Fewer sprint goals for the team to focus on
  团队需要专注的冲刺目标更少
• Do not assign sprint goals to people
  不要为人分配冲刺目标
• Keep the sprint goals achievable in one sprint
  保持一次冲刺可实现的冲刺目标
• Clear expectations and quantifiable sprint goals
  明确的期望和可量化的冲刺目标
• The entire team should decide on the sprint goals
  整个团队应确定冲刺目标

翻译自: https://medium.com/@buisteven/recognizing-a-disastrous-scrum-sprint-before-it-starts-53ca004d48d9

scrum流程 规划 冲刺