scrum和瀑布型_大量产品积压将Scrum转变为瀑布式方法

scrum和瀑布型

How many items do you have in your Product Backlog?

您的产品待办事项列表中有多少个项目？

What is the oldest item do you have?

你最老的东西是什么？

How often do you remove items from your Product Backlog?

您多久从产品待办事项列表中删除项目？

Answering these questions will help you to understand how your team is doing Scrum.

回答这些问题将帮助您了解团队的Scrum运作方式。

Responding to change over following a plan

响应计划变更

— Agile Manifesto

— 敏捷宣言

At the end of 2018, I joined a team as a Product Owner. When I looked at the Product Backlog, I was shocked. Some items were around two years old. The Product Backlog contained 150 items in total. I wondered why that happened, so I asked the Development Team, they told me, “We have a lot of things to build, but we haven’t found the time yet.”

在2018年底，我作为产品负责人加入了一个团队。 当我查看产品待办事项列表时，我感到很震惊。 有些物品大约有两年的历史。 产品待办事项列表总共包含150个项目。 我想知道为什么会这样，所以我问开发团队，他们告诉我：“ 我们还有很多东西要建立，但我们还没有找到时间。 ”

Over my journey, I have observed many Product Owners maintain long Product Backlogs. I also did that in the past. But I noticed this is counterproductive. It comes with many drawbacks, which inevitably leads to focus on irrelevant wishes, while avoiding what really matters.

在我的旅程中，我观察到许多产品负责人维护着长期的产品积压。 我过去也这样做。 但是我注意到这适得其反。 它有很多缺点，不可避免地导致关注无关紧要的愿望，同时又避免了真正重要的事情。

I’ve come across some approaches that help us to achieve better results with Product Backlog management. Allow me to share some of my insights. They can be useful for your scenario as well.

我遇到了一些方法，这些方法可以帮助我们通过产品待办列表管理获得更好的结果。 请允许我分享一些见解。 它们对于您的情况也可能有用。

产品积压应该有多大？ (How Big Should The Product Backlog Be?)

“No battle plan ever survives contact with the enemy”

“没有战斗计划能够幸免于与敌人的接触”

— Helmuth von Moltke, Prussian General

—普鲁士将军赫尔穆特·冯·莫尔特克

The Product Owner is accountable for the Product Backlog. The maintenance of this vital artifact can be daunting. We should keep it ordered in a way that maximizes the product value as fast as possible. Items on the top have more detailed information than the ones on a lower level. But the question is, how extensive should the Product Backlog be?

产品负责人负责产品积压。 这种重要人工制品的维护可能令人生畏。 我们应该以尽可能快地最大化产品价值的方式保持订购状态。 与较低级别的项目相比，顶部的项目具有更详细的信息。 但是问题是，产品待办清单应该有多广泛？

Let’s have a look at the Scrum Guide. In bold, you can find the essential aspects.

让我们看一下《 Scrum指南》。 以粗体显示，您可以找到基本方面。

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

产品积压是已知的产品 需要 的一切的有序 列表 。 这是要求的任何变化对产品所作的 单一 来源 。 产品 负责人负责 产品 待办事项 ， 包括其内容 ， 可用性和订购 。

— Scrum Guide, November 2017

— Scrum指南 ，2017年11月

One vital aspect of the Product Backlog is a list of everything that is known to be needed. I have observed that many Product Backlogs do not respect this aspect. If we have extensive Product Backlogs, let’s say six sprints of work. We are assuming we know up-front what to build for this time frame. But do we know that?

产品待办事项列表的一个重要方面是已知需要的所有内容的列表 。 我观察到许多产品积压订单都不尊重这一方面。 如果我们有大量的产品待办事项列表，那么我们可以说有6个工作冲刺。 我们假设我们预先知道在此时间范围内要构建什么。 但是我们知道吗？

From my experience, the more extensive the Product Backlog is, the more dangerous it becomes. In this case, we tend to fall into the build trap. If you observe one of the following behaviors, you probably fell into this trap:

根据我的经验，产品待办事项列表越广泛，就越危险。 在这种情况下，我们倾向于陷入构建陷阱。 如果您观察到以下行为之一，则可能会陷入此陷阱：

• The Product Backlog represents a list of features to build, instead of a direction to follow.
  产品待办列表表示要构建的功能列表，而不是要遵循的指示。
• The endless amount of wishes have little or no connection to each other.
  无休止的愿望彼此之间几乎没有联系。
• The size of the Product Backlog becomes an excuse to ignore new opportunities.
  产品待办事项列表的大小成为忽略新机会的借口。

If you maintain an extensive Product Backlog, you are missing the chance of embracing change. When we believe we know a lot upfront, we may end up building meaningless products.

如果您维护大量的产品待办事项列表，那么您将失去接受变更的机会。 当我们相信我们有很多前期知识时，我们可能最终会开发出毫无意义的产品。

Product Owners should insist on crafting a Product Vision. This is the first step to escape from the build trap. Until we have a clear vision, everything can become the destination. Without clear priorities, our results are, at best, mediocre.

产品负责人应坚持制定产品愿景。 这是摆脱构建陷阱的第一步。 除非我们有明确的愿景，否则一切都会成为目的地。 如果没有明确的优先事项，我们的结果充其量只是中等水平。

I believe that a good Product Backlog size is somewhere between two to four sprints. Which doesn’t mean the team cannot change anything. On the contrary, as the team learns more, the items should be adjusted accordingly.

我相信，一个好的产品待办事项列表的大小应介于2到4个Sprint之间。 这并不意味着团队不能改变任何东西。 相反，随着团队了解更多，项目应作相应调整。

您如何处理旧产品积压物品？ (What Do You Do With Old Product Backlog items?)

I’ve worked in many companies, and I noticed a typical behavior in every scenario. The Product Backlog had items that were too old. Some of them were older than three years. I never understood why teams kept many old items. This sign indicates a lack of an Agile mindset. The Product Backlog items are not contracts. We should be embrace change.

我在许多公司工作过，并且注意到每种情况下的典型行为。 产品待办事项列表中的商品过旧。 其中一些年龄超过三年。 我从来不明白为什么团队会保留许多旧物品。 这个迹象表明缺乏敏捷的心态。 产品待办事项不是合同。 我们应该拥抱变化。

Welcome changing requirements, even late indevelopment. Agile processes harness change forthe customer’s competitive advantage.

欢迎不断变化的需求，甚至是后期开发。 敏捷流程利用变更来获得客户的竞争优势。

— Agile Manifesto — Principles

— 敏捷宣言 —原则

Don’t fall in love with your Product Backlog items. Often maintain the items, remove what became obsolete so that you create space for the new. Don’t leave your Product Backlog bloated with old things that do not reflect the current need.

不要爱上您的产品待办事项。 经常维护项目，删除过时的项目，以便为新项目创建空间。 不要让您的产品积压中充斥着无法反映当前需求的旧东西。

My approach is simple; once a month, I remove all items older than three months from the Product Backlog. I don’t look at what I am removing because if in three months the items never made into a sprint, it means it was not necessary. The relevant items are clear, either stakeholders will come to us, or we will be aware of that somehow.

我的方法很简单； 我每月一次，从产品待办列表中删除所有三个月以上的物品。 我看不到要删除的内容，因为如果三个月内这些项目从未冲刺，则意味着没有必要。 相关项目很清楚，要么利益相关者会来找我们，要么我们会以某种方式意识到这一点。

Photo by Markus Winkler on Unsplash

Markus Winkler在 Unsplash上 拍摄的照片

I’ve never faced a problem by removing many items from the Product Backlog. But I wasted much time by keeping old items. For example, once I decided to approach each stakeholder to understand how relevant the old items were. Most stakeholders didn’t remember what was about, and some people were not even in the company anymore.

通过从产品待办列表中删除许多项目，我从来没有遇到过问题。 但是我通过保留旧物品浪费了很多时间。 例如，一旦我决定与每个利益相关者接触，以了解旧项目的相关性。 大多数利益相关者都不记得发生了什么，有些人甚至不在公司里。

A good Product Backlog item is no more than an invitation for a good conversation. If the item never made it to that point, just remove it from your Product Backlog, you will avoid wasting your time on irrelevant things. What is essential will always come back to your plate.

一个好的产品待办事项仅是进行良好对话的邀请。 如果该项目到现在还没有做到，只需将其从产品待办事项列表中删除，就可以避免浪费时间在无关紧要的事情上。 必不可少的将永远回到您的盘子。

If you can observe one of the following behaviors, you have a problem:

如果您可以观察到以下行为之一，则您有问题：

• Product Backlog items are never deleted.
  产品待办事项不会被删除。
• The Product Owner is reluctant to remove items because they can become important.
  产品负责人不愿删除物品，因为它们可能变得很重要。
• The Scrum Team is afraid of removing items without asking the stakeholders.
  Scrum团队害怕在不询问利益相关者的情况下删除项目。

“It is strange a difference comes from a subtraction.”― Natasha Tsakos

“奇怪的是，差值来自于减法运算。”-Natasha Tsakos

尾注 (Endnote)

To build meaningful products, we should keep our Product Backlog as lean as possible. By doing that, we can free our minds from distractions. Then, we create space to focus on what matters the most. Therefore, Product Owners need to craft a Product Vision. Without it, we run in circles.

要构建有意义的产品，我们应尽可能减少产品积压。 通过这样做，我们可以使我们的注意力从干扰中解放出来。 然后，我们创造空间来专注于最重要的事情。 因此，产品负责人需要制定产品愿景。 没有它，我们就会成群结队。

Until we have an Agile Mindset, we cannot benefit from Scrum. If we insist on keeping an extensive Product Backlog, we are missing the whole point of what being agile means. We don’t plan upfront; we set goals to achieve.

在拥有敏捷心态之前，我们无法从Scrum中受益。 如果我们坚持保留大量的产品待办清单，那么我们将失去敏捷意义的全部意义。 我们不预先计划； 我们设定了要实现的目标。

High-performing Scrum Teams know where they want to go, and they accept the road is unknown. But they are ready to embrace change and adapt on the way. Some approaches will fail; the team will learn from that. But the team will never plan everything upfront. Every day they will gain a little bit more clarity on how to reach the desired destination.

高绩效的Scrum团队知道他们想去哪里，并且他们接受未知的道路。 但是他们准备好接受变化并适应这种方式。 有些方法会失败； 团队将从中学习。 但是团队永远不会预先计划所有事情。 每天，他们将在如何到达所需目的地方面获得更多的清晰度。

Do you want to write for Serious Scrum or seriously discuss Scrum?

您要为《严重的Scrum》撰写文章还是认真讨论Scrum？

翻译自: https://medium.com/serious-scrum/extensive-product-backlogs-transform-scrum-into-a-waterfall-approach-2790a2b8c49b

scrum和瀑布型