命令休止符pin_无休止无聊的产品积压改进会议

命令休止符pin

A few Sprints into building a new product, the team starts to feel that they are struggling with regards to the process and practices required to deliver a potentially releasable product increment. One of which is Product Backlog Refinement (or “Refinement”) meetings - where the whole team gets together so a few of us can talk about the upcoming PBIs, while the rest listen passively to these discussions.

几个Sprint致力于开发新产品，团队开始感到他们在交付潜在的可发布产品增量所需的过程和实践方面都在挣扎。 其中之一是产品待办事项提炼(或“精炼”)会议-整个团队聚在一起，以便我们中的一些人可以谈论即将到来的PBI，而其他人则被动地听这些讨论。

If an item has a low estimate, we won’t worry about it again until Sprint Planning. If not, the same item is discussed again and the cycle repeats, as we often have gained little to no new knowledge about them between those Refinement Meetings. Still no progress in coping with uncertainty and lack of knowledge? Easy, we will plan a spike to do in the next Sprint.

如果某个项目的估算值较低，那么在Sprint Planning之前我们将不再担心。 如果没有，则再次讨论同一项目，并重复该周期，因为在那些改进会议之间，我们常常很少或几乎没有新的知识。 在应对不确定性和知识不足方面仍然没有进展吗？ 容易，我们将计划在下一个Sprint中加急。

GIF By Kissing Sisters GIF接吻姐妹

Those meetings feel repetitive, exhausting, and boring overall with “little to no value” for most of us. Does this sound familiar? I’ve got good news for you: it doesn’t need to be this way. We can do better!

这些会议对我们大多数人来说都是重复的，疲惫的，无聊的，而“几乎没有价值”。 这听起来很熟悉吗？ 我为您带来了一个好消息：不必这样。 我们可以做得更好！

在优化过程中我们应该考虑做什么？ (What should we consider to do during the refinement?)

What does the Scrum Team usually do during refinement and what does that look like? In my experience, the Scrum Team runs one or two refinement “meetings” during a sprint, where the members:

Scrum团队在提炼期间通常会做什么？ 以我的经验，Scrum团队在sprint期间运行一两次完善的“会议” ，其中成员：

• usually rewrite the PBI and/or add some acceptance criteria to it,
  通常重写PBI和/或向其中添加一些接受标准，
• sometimes split into separate “smaller” PBIs,
  有时会分成单独的“较小”的PBI，
• and add known sub-tasks that grasps what work we need to do.
  并添加已知的子任务，这些子任务掌握了我们需要做的工作。

But is it everything we can and should do during refinement? Let's examine what the Scrum Guide says about it:

但是，这是我们在优化过程中可以而且应该做的所有事情吗？ 让我们检查一下《 Scrum指南 》对此有何评论：

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. [1]

产品待办清单细化是向产品待办清单中的项目添加明细，估计和订单的行为 。 这是一个持续的过程，在此过程中，产品负责人和开发团队就产品待办事项的详细信息进行协作。 在产品积压细化过程中，将对项目进行检查和修订。 Scrum团队决定如何以及何时进行细化。 精炼通常消耗不超过开发团队容量的10％。 但是， 产品负责人可以随时更新产品待办事项，也可以由产品负责人自行决定。 [1]

So, Product Backlog Refinement shouldn’t only be a meeting session. While in most cases it manifests like that, at its core, it should be an ongoing process, an activity, which can happen at any time. Let’s analyze this description more deeply:

因此，产品待办事项列表优化不仅应该是会议。 尽管在大多数情况下它表现为这样，但它的核心应该是一个持续的过程，一项活动，可以随时发生。 让我们更深入地分析此描述：

细节 (The detail)

Product Backlog refinement is the act of adding detail (…) to items in the Product Backlog. [1]

产品待办清单细化是向产品待办清单中的项目添加详细信息 (…) 的行为 。 [1]

What is a detail? Think about it for a second. Is it only to write down a description? Or when we add some acceptance criteria to PBI it is a detail too? What about sketches, designs, known edge cases, external dependencies, data that backs up the idea, are those details to be added too?

什么是细节？ 想一想。 只是写下描述吗？ 或者，当我们向PBI添加一些验收标准时，它也是一个细节吗？ 草图，设计，已知的边缘情况，外部依存关系，支持该思想的数据又如何呢？这些细节也要添加吗？

估计 (The estimate)

Product Backlog refinement is the act of adding (…) estimates (…) to items in the Product Backlog. [1]

产品待办清单细化是对产品待办清单中的项目 添加 (…) 估计 (…) 的行为 。 [1]

Here it should be easier, as the Scrum Guide is specific about who should do it:

这里应该更容易一些，因为《 Scrum指南》具体说明了谁应该这样做：

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate. [1]

开发团队负责所有估算。 产品负责人可能会通过帮助开发团队了解和选择折衷方案来影响开发团队，但执行工作的人员会做出最终估算 。 [1]

and a side note:

并注意：

More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. [1]

基于更清晰和更多细节，可以进行更精确的估计。 顺序越低，细节越少。 [1]

But how, when, and in what units should we estimate? Should it be in Story Points, in time units, T-Shirt, man-days, etc.? If you estimate, do you know the purpose of that estimation? Why even bother with that question: How many hours/points is it?

但是，我们应该如何，何时以及以什么单位进行估算？ 应该以故事点，时间单位，T恤，工作日等为单位吗？ 如果您估算，您知道估算的目的吗？ 为什么还要打扰这个问题：多少小时/点？

命令 (The order)

Product Backlog refinement is the act of adding (…) order to items in the Product Backlog. [1]

产品待办清单细化是向产品待办清单中的项目添加 (…) 订单 的行为 。 [1]

It is rather straightforward, as the Scrum Guide says:

正如《 Scrum指南》所述，这非常简单。

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:(…)- Ordering the items in the Product Backlog to best achieve goals and missions; [2]

产品负责人是唯一负责管理产品待办事项列表的人。 产品待办事项管理包括：(…)- 订购产品待办事项中的项目以最好地实现目标和任务； [2]

But also two side notes here:

但这里还有两个注意事项：

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. [1]

与较低顺序的产品相比，较高顺序的产品积压项目通常更清晰，更详细。 [1]

and

和

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. [2]

产品负责人可以完成上述工作 ， 或由开发团队完成 。 但是， 产品负责人仍然负责 。 [2]

In other words - the Development Team may order the items in the Product Backlog on Product Owner’s behalf. Nevertheless, the Product Owner remains accountable for that this order reflects how to best achieve goals and missions.

换句话说，开发团队可以代表产品负责人订购产品待办事项列表中的项目。 但是，产品负责人仍然对此订单负责，因为它反映了如何最好地实现目标和任务。

Summary of all the points above:

以上所有要点的摘要：

• Refinement is an ongoing process, not “one meeting” in a sprint.
  优化是一个持续的过程，而不是冲刺中的“一次会议”。
• In fact, PBI can be refined without any meeting at all. You can add the details, estimates, order, etc., during the Sprint without a meeting as the team members figure out what needs to happen on the go.
  实际上，无需进行任何会议就可以完善PBI。 您可以在Sprint期间添加详细信息，估计值，订单等，而无需开会，因为团队成员可以确定旅途中需要做什么。
• You perform an act of refinement each time you add such a detail, whether or not it is a rewrite of the initial PBI, when you add more insights such as acceptance criteria, edge cases, data, sketches, designs, etc.
  每当您添加更多详细信息(例如验收标准，边沿案例，数据，草图，设计等)时，无论您添加这样的细节(无论是否重写初始PBI)，您都将执行一次细化操作。
• You perform an act of refinement each time you change the order of items in the Product Backlog.
  每次更改产品待办事项列表中的项目顺序时，您都会执行改进操作。
• You perform an act of refinement each time you add an estimate to PBI.
  每次向PBI添加估算时，您都会执行改进操作。

我们为什么要精炼？ (Why do we do refinement?)

Let’s assume that we know more or less what to do “during refinement”. Do we also know why we are doing it?

假设我们或多或少地知道“精炼期间”该做什么。 我们也知道为什么要这么做吗？

Consider this fragment of the Scrum Guide:

考虑一下Scrum指南的以下片段：

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box.

将对即将到来的Sprint占用开发团队的产品待办事项 进行细化，以便可以在Sprint时限内合理地“完成”任何一项。

Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. [1]

开发团队可以在一个Sprint中 “完成”的产品待办事项 被视为“准备就绪” ，可以在Sprint计划中选择。 [1]

What does “Ready” mean anyway? When you are learning to take an assessment or exam, when do you consider that you are “ready” to take it? More likely you do it when you feel confident enough that you are prepared well and the risk is not overwhelmingly high to give it a shot and you can accept that risk.

无论如何，“就绪”是什么意思？ 当您学习参加评估或考试时，您何时认为自己“准备”参加评估或考试？ 当您对自己已经做好充分准备充满信心时，您就更有可能这样做，并且冒险的机率不会很高，可以接受这种风险。

Perhaps we can say that:

也许我们可以这样说：

By the act of refinement of Product Backlog Items, we strive to cope with uncertainty and to reduce the risk, so that we can work on considered items with more confidence within current and upcoming Sprint(s).

通过改进产品待办事项的行为，我们努力应对不确定性并降低风险，以便我们可以在当前和即将推出的Sprint中更加自信地处理已考虑的项目。

尾注 (Endnote)

It is good to have an opportunity to assess the top of the Product Backlog with the whole team within a “refinement meeting”. It is a perfect place to hear a wider voice and focus on what’s next as a team, but we should remember that it is not everything.

有机会在“优化会议”中与整个团队一起评估产品待办事项的顶部是一件好事。 这里是聆听更广泛声音并专注于团队下一步工作的理想场所，但我们应该记住，这还不是全部。

It is perfectly fine if, during the sprint, the Product Owner and different Development Team members collaborate in smaller groups together, or even sometimes alone, to refine upcoming PBIs.

如果在冲刺期间，产品负责人和不同的开发团队成员一起(甚至有时单独)以较小的团队协作来完善即将到来的PBI，那将是非常好的。

We should trust each other and remember that we should have the courage to work on tough problems and respect each other to be capable, independent people. Those are two out of five Scrum Values that we may recall here, if not more [3].

我们应该相互信任，并记住，我们应该有勇气努力解决棘手的问题 ， 相互尊重，成为有能力的独立人士。 如果不是更多的话，那么这就是我们可能会回忆起的五个Scrum值中的两个[3]。

细化实验 (Experiment with Refinement)

I encourage you to challenge your approach to Product Backlog Refinement. There is no silver bullet on how to do it, and definitely, a single or couple of meetings where only some people talk and other passively listen is not the finish line here. In the end:

我鼓励您挑战产品积压细化的方法。 没有做到这一点的灵丹妙药，当然，只有一些人讲话而其他人被动地听的一次或几次会议并不是这里的终点。 到底：

(…) The Scrum Team decides how and when refinement is done. (…) [1]

(…) Scrum团队决定改进的方式和时间。 (…)[1]

So go, try more things, some new unique ideas, and find your way. Maybe you can do more than simply rewrite the initial PBI description?

因此，尝试更多的事情，一些新的独特想法并找到自己的方式。 也许您不仅可以简单地重写初始PBI描述，还可以做更多的事情？

GIF By Gordon Ramsay’s 24 Hours To Hell And Back GIF Gordon Ramsay的24小时地狱与后退

Source:[1] the Scrum Guide, Nov 2017, page 15[2] the Scrum Guide, Nov 2017, page 6[3] the Scrum Guide, Nov 2017, page 5

来源： [1] Scrum指南 ，2017年11月，第15页[2] Scrum指南 ，2017年11月，第6页[3] Scrum指南 ，2017年11月，第5页

Do you want to write for Serious Scrum or seriously discuss Scrum? 您要为《严重的Scrum》撰写文章还是认真讨论Scrum？

翻译自: https://medium.com/serious-scrum/endless-and-boring-product-backlog-refinement-meetings-e98f6a4a46ed

命令休止符pin