如何定义专注如何专注_不要专注于估计而是专注于共同的理解-优快云博客

本文探讨了在Scrum团队中，产品负责人和开发团队如何通过建立共识而非过分关注估算，来提高会议效率和项目成功率。文章强调了理解问题本质的重要性，以及如何通过有效的沟通和团队合作，确保每个人都明白要解决的实际问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

如何定义专注如何专注

At 11:00 a.m. on Thursday, we had our weekly refinement session. As a Product Owner, I wanted to get five items ready for the upcoming sprint. Unfortunately, we refined only two items during the whole session. I left the room, frustrated. I wondered, why do we take so long to estimate each item? Why do we discuss each minor detail?

在星期四上午11:00，我们进行了每周一次的优化。作为产品负责人，我想为即将开始的冲刺准备五件物品。不幸的是，我们在整个会议期间仅细化了两个项目。我沮丧地离开了房间。我想知道为什么我们要花这么长时间估算每个项目？ 为什么我们讨论每个次要细节？

The hard truth, we focused on the irrelevant aspects. As a Product Owner, I wanted the estimates for each item, while the team wanted to define precisely how to implement the solution. We missed the whole point. It’s not about the estimates. It’s all about building shared understanding.

硬道理，我们专注于不相关的方面。作为产品负责人，我希望对每个项目进行估算，而团队则希望精确定义如何实施解决方案。我们错过了整点。这与估计无关。这都是关于建立共识的。

“Shared understanding is when we both understand what the other person is imagining and why.”― Jeff Patton

“共同的理解是我们俩都了解对方在想什么以及为什么。”-杰夫·帕顿(Jeff Patton)

I learned how to escape from estimation prison the hard way. Building shared understanding can free us from the trap of transforming Product Backlog items into requirements. Once we build shared understanding, solutions to real problems become evident. Allow me to share my learnings with you. Then, hopefully, you can avoid the pitfalls I fell into.

我学会了如何从困难的监狱中逃脱。建立共识可以使我们摆脱将产品待办事项转换为需求的陷阱。一旦我们建立了共识，就可以解决实际问题。请允许我与您分享我的经验。然后，希望您可以避免我陷入的陷阱。

当估计导致令人失望的结果时 (When Estimates Lead to Disappointing Results)

If you are too picky about estimates, you are missing the point. Estimates are imprecise by nature. As human beings, we are horrible at predicting how long it takes to do something we don’t know. Building products is full of uncertainties. We need to validate our hypothesis on the way. Accepting we don’t know everything upfront is a required attitude to succeed.

如果您对估计值过于挑剔，那么您将错过这一点。估算本质上是不精确的。作为人类，我们很难预测完成不知道的事情需要多长时间。建筑产品充满不确定性。我们需要在途中验证我们的假设。接受我们并不知道一切都是成功的必备态度。

Over the last eight years, I had the chance to be part of many Scrum Teams. I could observe many refinement sessions from different teams. Surprisingly, most refinements focused on the wrong aspects. Despite using Scrum, many companies still keep the same old traditional mindset. Treating Product Backlog items as requirements makes disaster inevitable.

在过去的八年中，我有机会成为许多Scrum团队的一员。我可以观察到来自不同团队的许多改进会议。令人惊讶的是，大多数改进都集中在错误的方面。尽管使用Scrum，但许多公司仍然保留着相同的传统观念。将产品待办事项视为需求是不可避免的。

Let me share with you some common mistakes. If you experience one of them, you have an excellent opportunity for improving your team’s outcome:

让我与您分享一些常见的错误。如果您遇到其中之一，那么您就有绝佳的机会改善团队的成果：

Focus on what to build instead of why: once the Product Owner presents the PBI, the team discusses directly what is needed to build and how to do it. The team neither challenges the Product Owner why is it a problem worth solving, nor does the Product Owner presents the problem from the user perspective.
专注于构建什么而不是为什么 ：一旦产品负责人提交了PBI，团队就直接讨论构建什么以及如何做。团队既不会挑战产品负责人，为什么这是一个值得解决的问题，也不会从用户的角度提出问题。
The team urges to discuss how to implement the Product Backlog items: many Development Teams insist on talking about the implementation before estimating the items. It’s a trap to focus on the technical aspects if we don’t know the problem. The technical implementation should not be the focus of the estimation. By ignoring the real problem, we may end up with a feature that solves no problem at all.
团队敦促讨论如何实施Product Backlog项目 ：许多开发团队坚持在评估项目之前谈论实现。如果我们不知道问题所在，那就是专注于技术方面的陷阱。技术实施不应成为估算的重点。通过忽略真正的问题，我们可能最终获得了一个根本解决不了任何问题的功能。
Tools lead the conversation: the whole refinement session happens behind screens. The Product Owner opens the Product Backlog tool, e.g., Jira, and focus on discussing each item and updating it. The session is boring. Everyone is sitting and talking about the items. No one goes to a whiteboard to draw the thoughts. The software resulting from this exchange will eventually be disappointing due to the lack of shared understanding.
工具引导对话 ：整个优化会话在屏幕后面进行。产品负责人打开产品积压工具，例如Jira，并专注于讨论和更新每个项目。会话很无聊。每个人都坐在那里谈论这些物品。没有人去白板上写下想法。由于缺乏共识，这种交流产生的软件最终将令人失望。

Individuals and interactions over processes and tools

个人与流程和工具之间的互动

— Agile Manifesto

— 敏捷宣言

I’ve fallen into these pitfalls multiple times. It took me some time to understand why we failed to deliver meaningful results. Until I learn what estimates are about, I had to deal with many unsatisfied stakeholders. Estimates are always a hot topic. Some teams use Story Points, T-Shirt Size, or even No Estimates. However, the approach doesn’t matter. The point is gaining understanding so that the team knows precisely which problem to solve.

我已经多次陷入这些陷阱。我花了一些时间来理解为什么我们未能提供有意义的结果。在我了解估计值之前，我不得不与许多不满意的利益相关者打交道。估算始终是热门话题。一些团队使用故事点数，T恤尺寸，甚至没有估算值。但是，方法并不重要。关键是要获得理解，以便团队准确知道要解决的问题。

Sign of wrong way — Photo by Free To Use Sounds on Unsplash

If we try to find the answer in the Scrum Guide, we can’t. It’s vague. Scrum leaves us alone when it comes to estimates. We have to figure that out on our own.

如果我们尝试在《 Scrum指南》中找到答案，我们将无法找到答案。含糊不清。当涉及估计时，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.

产品Backlog细化 添加细节，估计和为了在积压的产品项目的行为。这是一个持续的 过程中，产品 负责人及开发团队的产品 Backlog 项目的细节 进行合作 。在产品待办事项表提炼 期间，将对项目进行审核和修订。 Scrum团队 决定细化完成 的方式和时间。

— The Scrum Guide, November 2017

— Scrum指南，2017年11月

建立共识有助于我们走向成功 (Building Shared Understanding Lead Us To Success)

Regardless of how you write your Product Backlog items and estimate them, your ultimate goal should be to build a shared understanding with the team.

无论您如何编写产品待办事项并进行估算，最终目标都是与团队建立共识。

As Product Owners, it’s easy to forget that the Development Team doesn’t have the same understanding as we have. We may fall in love with our User Stories. We want to discuss how to implement something, instead of clarifying which problem to solve.

作为产品负责人，很容易忘记开发团队对我们的了解不尽相同。我们可能会爱上我们的用户故事。我们要讨论如何实现某些事情，而不是澄清要解决的问题。

Great Product Owners master the art of communication. They know how to present a problem to the team. The refinement sessions are engaging. Every team member asks many questions to understand clearly what kind of problem is solved for whom and why it is worth solving.

伟大的产品负责人掌握了沟通的艺术。他们知道如何向团队提出问题。精修课程吸引人。每个团队成员都会问许多问题，以清楚地了解为谁解决了什么样的问题以及为什么值得解决。

“Remember: at the end of the day, your job isn’t to get the requirements right — your job is to change the world.”― Jeff Patton

“请记住：归根结底，您的工作不是满足正确的要求-您的工作是改变世界。”-杰夫·帕顿(Jeff Patton)

Meaningful refinement sessions present the following characteristics:

有意义的优化会话具有以下特征：

The why leads the discussion: the Product Owners clarifies the reason behind each Product Backlog item. The Development Team doesn’t discuss what to build until the problem is crystal clear.
为什么要进行讨论 ：产品负责人阐明了每个产品待办事项的背后原因。在问题明确之前，开发团队不会讨论要构建什么。
The team has a clear picture of the end-user: the Product Owner speaks from the user perspective. The team is curious to understand for whom they are building something.
团队对最终用户有清晰的了解 ：产品负责人从用户的角度发言。团队很想了解他们正在为谁制造东西。
What to build is a team activity: the Product Owner comes with a problem to solve instead of a solution to build. Once the whole Scrum Team understands the problem, they evaluate which solutions could solve this problem.
建立的是团队活动 ：产品负责人附带要解决的问题，而不是要建立的解决方案。一旦整个Scrum团队了解了问题，他们就会评估哪些解决方案可以解决该问题。
Share different perspectives: the estimates bring an opportunity to get different perspectives. The Development Team is eager to understand the other team members’ views on how to solve the problem. The discussion around the estimates is more critical than the estimate itself.
分享不同的观点 ：估算带来了获得不同观点的机会。开发团队渴望了解其他团队成员对如何解决问题的看法。关于估算的讨论比估算本身更为关键。

Beyond all of these points, don’t forget that as a Product Owner. You should bring problems to your team that the users want them solved.

除了所有这些要点，作为产品负责人，不要忘记这一点。您应该给团队带来用户希望他们解决的问题。

“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.”― Marty Cagan

“如果没有值得建设的东西，那么您的工程团队有多好也没关系。”-马蒂·卡根(Marty Cagan)

尾注 (Endnote)

Using estimates as an opportunity to build a shared understanding is a characteristic of high-performing teams. If we insist on having precise estimations, we do not have an agile mindset. We need to accept we don’t know everything upfront.

高绩效团队的特征是利用估计作为建立共识的机会。如果我们坚持要进行精确的估算，那么我们就没有敏捷的心态。我们需要接受我们并不了解所有事情。

It’s a deadly pitfall to focus on the estimates. By doing that, we may forget to discuss what leads us to success. The discussion should be about clarifying the problem we want to solve so that the team can find proper solutions. Use your time wisely, focus on what will put you in a successful track: shared understanding.

专注于估计是一个致命的陷阱。这样，我们可能会忘记讨论导致我们走向成功的原因。讨论应该围绕澄清我们要解决的问题，以便团队可以找到适当的解决方案。明智地利用您的时间，专注于使您成功的道路：共同的理解。