The Scrum Guide is minimal — it defines a bare-bones framework, on top of which you are expected to add practices to establish a viable process. If you want to start fresh with Scrum, the framework as described by the guide is not enough to go by. In this series, I will introduce you to some common building blocks of a Scrum-based process. Even if you’re already an experienced Scrum practitioner it’s never a bad idea to go back to the basics, validate your assumptions, and share some best practices. Let’s dive in!

Scrum指南极少，它定义了一个基本框架，您希望在此框架上添加一些实践来建立可行的流程。 如果您想从Scrum重新开始，那么指南所描述的框架还不够。 在本系列中，我将向您介绍基于Scrum的流程的一些常见构建基块。 即使您已经是一名经验丰富的Scrum从业人员，回到基础知识，验证您的假设并分享一些最佳实践也绝不是一个坏主意。 让我们潜入吧！

冲刺板 ( The Sprint Board )

This is the guidance we get from the Scrum Guide regarding visualizing our Sprint works:

这是我们从Scrum指南获得的有关可视化Sprint作品的指南：

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum…The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint

Sprint待办事项列表是一个具有足够详细信息的计划，可以在每日Scrum中了解进度的变化…Sprint待办事项列表是开发团队计划在Sprint期间完成的工作的高度可见的实时图片。

(source: The Scrum Guide ™ 2017 https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog )

(来源：Scrum Guide™2017 https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog )

Despite this open-ended guideline, in practice, almost everyone uses something derived from a Kanban board to visualize their Sprint Backlog. I call it here “the Sprint Board” as opposed to the more commonly used “Scrum Board” to decouple this common practice from the Scrum framework (the Kanban based board is not actually part of the framework, the word “Board” doesn’t appear anywhere in the Scrum Guide) and because the board is typically used to visualize only the Sprint Backlog (when it includes a Backlog column it could be more appropriate to call it a Scrum Board).

尽管有这个开放性的准则，但实际上，几乎每个人都使用 看板中的 某些东西来可视化其Sprint Backlog。 我在这里将其称为“ Sprint委员会”，而不是将这种常见做法与Scrum框架脱钩的更常用的“ Scrum委员会”(基于看板的委员会实际上并不是该框架的一部分，“ Board”一词并不出现在Scrum指南的任何位置)，并且由于该板通常仅用于可视化Sprint Backlog(当它包含Backlog列时，将其称为Scrum板可能更合适)。

The Sprint Board is a set of columns representing the state the work is in (“To do”, “In progress”, etc.), under which the Sprint items are placed to indicate the state they’re in. When using a physical board it is common to use colorful Post-It notes with short descriptive text written with a thick marker for easy reading. The board is placed somewhere visible so everyone can see the state of the Sprint at a glance. During the Daily Scrum, the team typically stands around the board and updates the state of each item together.

Sprint板是一组列，代表工作的状态(“待办事项”，“进行中”等)，在这些列下放置Sprint项以指示其所处的状态。板上通常使用彩色的便利贴，并在其上加上简短的说明文字，并用粗笔标记，以方便阅读。 评估板放置在可见的地方，因此每个人都可以一目了然地看到Sprint的状态。 在每日Scrum期间，团队通常围着董事会站着，一起更新每个项目的状态。

常见的Sprint Board陷阱 ( Common Sprint Board pitfalls )

Too many columns : Some teams believe that the more columns they have the more transparent their board is or the more “comprehensive” their process is. This is a bit of a “more is better” kind of thinking, but actually what we want to strive for is to simplify the process.

列过多 ：有些团队认为，列越多，董事会的透明度​​就越高，或者过程越“全面”。 这有点“多多益善”的想法，但实际上我们要争取的是简化流程。

Handover bottlenecks: In many teams, specific columns “belong” to specific team members. For example, in teams where only a QA person is allowed to perform a review, tickets that end up in the review column could only be moved out of it by the QA person. Hence, that column “belongs” to the QA. Only they are allowed to move tickets out of it. This kind of approach (mockingly nicknamed “Mini Waterfall”) leads to bottlenecks, where inadvertently the speed of work difference between the different “owners” of columns would lead to tickets accumulating in one of those columns, leading to some of the team having nothing to do while others having their hands full. What you want to strive towards is a board where everyone can participate in moving a ticket towards done, no matter which state the ticket is in.

移交瓶颈： 在许多团队中，特定的列“属于”特定的团队成员。 例如，在仅允许QA人员进行审阅的团队中，最终进入“审阅”列的票证只能由QA人员从审阅栏中移出。 因此，该列“属于”质量检查。 只有他们被允许将票移出。 这种方法(俗称“迷你瀑布”)会导致瓶颈，在这种情况下，不同的“所有者”列之间的工作速度差异会无意中导致票证在这些列之一中积累，从而导致一些团队一无所有当别人举手时做的事情。 您想要争取的是一个董事会，每个人都可以参与将票证移至完成状态，无论票证处于哪个状态。

整理积压 ( Organizing the Backlog )

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

产品待办列表列出了所有功能，功能，要求，增强功能和修补程序，这些功能，功能，要求，增强功能和修复程序构成了将来版本中要对产品进行的更改。 产品待办事项项具有描述，订单，估计和值的属性。 产品待办事项通常包括测试说明，这些说明将在“完成”时证明其完整性。

(source: The Scrum Guide ™ 2017 https://www.scrumguides.org/scrum-guide.html#artifacts- productbacklog )

(来源：Scrum Guide™2017 https://www.scrumguides.org/scrum-guide.html#artifacts- productbacklog )

The Scrum Guide only recognizes Product Backlog Items (PBIs). How these items actually look like is left open by the Scrum Guide. What follows are some common practices to communicate these PBIs.

《 Scrum指南》仅识别产品积压项目(PBI)。 这些项目的实际外观由Scrum指南保留。 以下是传达这些PBI的一些常见做法。

用户故事 ( User Stories )

User Stories are a common convention for writing PBIs. Instead of describing the work to be done, they capture the need or wish of the user that the work will fulfill, leaving the implementation details open to discussion.

用户故事是编写PBI的常见约定。 他们没有描述要完成的工作，而是捕获了用户将要完成工作的需求或希望，而实现细节尚待讨论。

A common format for User Stories is:

用户故事的常见格式是：

As a …. <role/persona>

作为一个 …。 <角色/角色>

I want …. <behavior>

我想要 …。 <行为>

So that … <value>

这样... <值>

( source: Mike Cohn, User Stories Applied (Boston: Addison-Wesley, 2004), 135. )

( 来源：Mike Cohn，《用户故事应用》(波士顿：Addison-Wesley，2004年)，第135页。 )

For example:

As a Line Manager

作为 直属经理

I want to see an overview of my subordinates’ contract expiry dates

我想 查看下属的合同到期日期的概述

So that I can renew contracts on time

这样 我可以按时续签合同

The benefit of the User Story over the more straightforward “to do” task is that it encourages conversation by providing context. Imagine we had the following task instead of the above User Story:

与更直接的“要做”任务相比，用户故事的好处是它通过提供上下文鼓励对话。 想象一下，我们有以下任务而不是上面的用户故事：

Create a table showing the name of the subordinate and their contract expiry dates

创建一个表，显示下属的名称及其合同的到期日期

It could very well be that when the team implements the User Story they will end up with this exact screen. But it could also be that upon reading the User Story the discussion on how the Story’s intent could be achieved would bring up new suggestions that weren’t thought of when the ticket was created. Maybe instead of creating a whole new screen, the same value could be delivered with less work simply by sending a reminder email before a contract is about to expire?

很好的是，当团队实施用户案例时，他们最终将获得这个确切的屏幕。 但是也可能是，在阅读了用户故事之后，关于如何实现故事意图的讨论将提出新的建议，而这些建议在创建票证时并未想到。 也许不是创建一个新的屏幕，而是只需在合同即将到期之前发送提醒电子邮件，便可以用更少的工作交付相同的价值？

By providing the context as to WHY we’re building this feature and omitting the HOW, the User Story encourages conversations, unlike the to-do task which simply dictates what is to be done.

通过提供有关WHY的上下文，我们将构建此功能并省略HOW，而 与待办事项仅说明要完成的任务不同 ，用户故事鼓励了对话 。

常见用户故事陷阱 ( Common User Story pitfalls )

Technical Persona: You want to avoid choosing a persona that represents a technical role. Examples to avoid: “As a Product Owner I want feature X So that we could later implement feature Y”, or “as a developer, I want unit tests so that the code will be easy to refactor”. These kinds of non-user stories discourage the capturing of intent and return us to thinking in terms of solution. User Stories should only be used to capture the needs of your users or stakeholders. A stakeholder example would be your legal department requesting that the system would be GDPR compliant so that the company would not be sued. That’s a valid User Story.

技术角色： 您要避免选择代表技术角色的角色。 应避免的示例：“作为产品负责人，我需要功能X，以便我们以后可以实现功能Y”，或“作为开发人员，我需要单元测试，以便代码易于重构”。 这类非用户的故事会阻止捕获意图，并让我们重新思考解决方案。 用户故事仅应用于捕获用户或利益相关者的需求。 利益相关方的例子是您的法律部门，要求该系统符合GDPR的要求，以便不起诉该公司。 那是一个有效的用户故事。

Too broad of a persona: If all your User Stories start with “As a user I want..”, you’re omitting vital context. Your users are not all the same and their wishes are not uniform. Try to capture the user’s subgroup, state of mind, or intent when they have the need you’re addressing. “As an angry reader I want…” is immediately more evocative than “As a user I want…”.

人物角色太宽泛： 如果您的所有用户故事都以“作为我想要的用户..”开头，则您将忽略重要的背景信息。 您的用户并不完全相同，他们的愿望也不统一。 当他们有您要解决的需求时，尝试捕获他们的子组，心境或意图。 “作为我想要的愤怒的读者……”比“作为我想要的用户……”更具启发性。

史诗 ( Epics )

Epics are items that are too big to fit into a Sprint (Epic = Long story). In Scrum the team is expected to choose PBIs it can complete within a Sprint when planning. However, not all PBIs are small enough to be completed within a Sprint. Before pulling them into a sprint they need to be broken down further until they can fit, which is often done as part of a Backlog Refinement. Refining PBIs is time-consuming and therefore you typically only want the highest priority PBIs in your backlog refined, those that are likely to be pulled into the upcoming Sprint.

史诗是那些太大而无法放入Sprint的物品(史诗=长篇小说)。 在Scrum中，预计团队将在计划时选择可以在Sprint中完成的PBI。 但是，并非所有的PBI都足够小，无法在Sprint中完成。 在将它们拉入冲刺之前，需要将它们进一步分解，直到适合为止，这通常是“积压细化”的一部分。 精炼PBI非常耗时，因此，您通常只希望精简积压中优先级最高的PBI，这些PBI可能会拖入即将到来的Sprint中。

Epics allow you to keep items in your backlog without investing time in refining them. They represent work to be done that only needs actual refinement when their time to be implemented is approaching. At that point, they could be broken down into multiple User Stories so that the work can fit in a Sprint.

Epics允许您将项目保留在积压中，而无需花费时间来完善它们。 它们表示仅在实际实施时间临近时才需要实际改进的工作。 到那时，可以将它们分解为多个用户故事，以便可以使工作适合于Sprint。

Typically the highest priority items in the backlog are User Stories, and as you go down the Backlog you see more Epics.

通常，待办事项列表中优先级最高的项是“用户故事”，当您查看待办事项列表时，会看到更多的史诗。

史诗般的陷阱 ( Common Epic pitfalls )

Open-ended Epics : Some management systems (e.g. Jira) encourage the use of Epics as containers for certain types of activities. There could be a “Technical debt” Epic to contain all technical debt stories or “Checkout Page” Epic to contain any work related to that page. Of course, Technical Debt is never fully paid off and the Checkout Page could always use more work, and therefore these container Epic tend to never be removed either, leading to an ever-growing list of immortal Epics that is tough to manage. Create Epics with specific intent and once that intent is captured by Sprint sized stories, remove the Epics.

开放式史诗 ：某些管理系统(例如Jira)鼓励将史诗用作某些类型活动的容器。 可能会有一个“技术债务”史诗包含所有技术债务的故事，或者可能有一个“结帐页面”史诗包含所有与该页面相关的工作。 当然，技术债务永远无法完全还清，并且“结帐页面”总是可以使用更多的工作，因此这些容器Epic也永远不会被移除，从而导致难以管理的永生史诗清单不断增加。 创建具有特定意图的史诗，一旦该意图被Sprint大小的故事捕获，请删除史诗。

Highly detailed Epics: The intent of Scrum is to complete work and release working software on a regular basis in order to facilitate learning over your product and your market. Learning is then captured in the backlog by adding, removing, or modifying PBIs. Therefore the content of your lower priority items on your backlog tends to be volatile. You don’t want to spend a lot of time defining these items as their content can and should change as your product evolves. The time you spend defining these items in detail will be wasted once they need to be modified due to changes in the system or the system’s context. The detailing work should come when the Epics are broken down to Sprint sized User Stories.

高度详细的史诗： Scrum的目的是定期完成工作并发布可运行的软件，以促进对您的产品和市场的了解。 然后，通过添加，删除或修改PBI将学习记录在积压中。 因此，您的待办事项列表中优先级较低的项目的内容往往是不稳定的。 您不想花很多时间来定义这些项目的内容，因为它们的内容可以并且应该随着产品的发展而变化。 一旦由于系统或系统上下文的更改而需要修改这些项目，您花在详细定义这些项目上的时间就会浪费掉。 当Epics分解为Sprint大小的User Stories时，详细工作应该到来。

全部放在一起 ( Putting it all together )

The Scrum Guide does not give specific guidance on how to implement its various requirements and therefore the use of additional techniques and processes on top of the Scrum Guide is unavoidable. However, since these techniques are not unique to Scrum it is important to know how to use them in a way that still keeps true to the intention of the Scrum framework.

《 Scrum指南》未就如何实现其各种要求提供具体指导，因此不可避免地会在《 Scrum指南》的顶部使用其他技术和流程。 但是，由于这些技术不是Scrum独有的，因此重要的是要知道如何以仍然符合Scrum框架意图的方式使用它们。

In this part of the series, I covered some common techniques to organize and visualize the Sprint backlog and the Product backlog following the requirements of the Scrum Guide. In the next part, I will introduce techniques for estimation and planning.

在本系列的这一部分中，我介绍了一些按照Scrum指南的要求组织和可视化Sprint待办事项和产品待办事项的常用技术。 在下一部分中，我将介绍估计和规划技术。

Always keep in mind that these practices are intended to serve the team and their ability to deliver highly valuable products. They are not a goal in itself, therefore do not hesitate to change or drop practices that don’t make sense or don’t deliver results.

始终牢记，这些做法旨在为团队及其提供高价值产品的能力服务。 它们本身并不是目标，因此可以毫不犹豫地更改或放弃没有意义或无法带来结果的做法。

Got any must-have practice that you think belongs in this guide? Please let me know in the comments!

有任何您认为属于本指南的必备练习吗？ 请在评论中让我知道！

scrum实战指南The Scrum Guide is minimal — it defines a bare-bones framework, on top of which you are expected to add practices to establish a viable process. If you want to start fresh with Scrum, the fra... Scrum 是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织 创造价值。 简而言之， Scrum 需要 Scrum Master 营造一个环境，从而： 1. 一名 Product Owner 将解决复杂问题所需的工作整理成一份 Product Backlog。 2. Scrum Team 在 一个 Sprint 期间将选择的工作转化为价值的 Increment。 3. Scrum Team 和利益攸关者检视结果并为下一个 Sprint 进行调整。 4. 重复 Scrum 是易于理解的。原封不动地去尝试，并确定其哲学、理论和结构是否有 创造价值。 简而言之， Scrum 需要 Scrum Master 营造一个环境，从而： 1. 一名 Product Owner 将解决复杂问题所需的工作整理成一份 Product Backlog。 2. Scrum Team 在 一个 Sprint 期间将选择的工作转化为价值的 Increment。 3. Scrum Team 和利益攸关者检视结果并为下一个 Sprint 进行调整。 4. 重复 Scrum 是易于理解的。原封不动地去尝试，并确定其哲学、理论和结构是否有助于实现目标和创 造价值。 Scrum 框架故意不完整，仅定义了实施 Scrum 理论所需的部分。 Scrum 建立在其使用者 的集体智慧之上。 Scrum 的规则没有为人们提供详细的使用说明，而是指导他们之间的关系和互 在 Scrum 框架中，可以使用各种不同的过程、技术和方法。 Scrum 可以将一些已有的 实践 包装进 来，也可以甄别出非必须的 实践 。 Scrum 可以凸显当前管理、环境和工作技术的相对成效，以便 可以进行改进。