为什么我不强调Sprint目标

译者序：Sprint目标（Goal）作为Scrum指南中一个核心概念，用来聚焦团队目标、履行团队承诺、判定Sprint是否成功。但在Sprint目标实践方式上，可能不同团队会有不同的方法，在酷家乐的敏捷实践中亦是如此。本文针对Sprint目标提出了一种有趣的观点，希望能给大家带来一些启发。

本文作者Mike Cohn是敏捷联盟和Scrum联盟的联合创始人，在这两家公司的董事会中任职多年，是《Scrum敏捷软件开发》的作者。如果你对敏捷比较熟悉，那你对这位大师一定不会觉得陌生。

本文为原创翻译，并已获得作者授权。

为什么我不强调Sprint目标

我承认对Scrum中的Sprint目标，是会感到有些矛盾的。我指导团队尝试创建Sprint目标，但同时也告诉他们，并非每个团队都能从Sprint目标中受益。

这是一种亵渎？也许吧。

Sprint Goal的定义正如其名，是Sprint的唯一目标。

我非常喜欢这个定义。我花了很多时间来建议组织缩小对他们将要实现的目标的关注范围，无论是一年、一个季度，或者是一次Sprint。对于一个组织或团队来说，他们选择一个目标的时候通常就像我在吃自助餐时一样，在盘子里装一点这个、装一点那个、再装点其他东西。

有时Sprint不能专注于单一目标。有些团队需要完成多项任务。例如，一个数字化代理商下的一个团队可以同时为一个客户建立一个新网站，为第二个客户做一些中等规模的改造工作，并为另外五个客户做一些小错误修复或编辑。

那他们的Sprint目标应该如何写？目标应该集中在新网站上吗？在Sprint期间，新网站将消耗最多的工作？或者，如果这些是为公司最重要的客户而做的，它是否应该把重点放在小编辑上？

有些团队将所有这些合并为一个目标，比如“完成我们承诺的七个用户故事”。

这种做法并没有什么用。它不能提供一个好的目标所能提供的清晰性，而且它过于宽泛，无法让团队专注于一个单一的目标。那些以“完成我们承诺的用户故事”作为Sprint目标的团队，已经很“高效”得放弃了Sprint目标。

设置Sprint目标的目的

Sprint目标的目的是为了让团队将注意力集中在最需要实现的目标上。我记得这在20世纪90年代末Scrum早期是相当重要的。当时，所有团队都进行了为期四周的Sprint，没有人进行我们今天称之为需求澄清的工作，用户故事也没有在极限编程中使用。

那时团队会忽略他们在做什么。我清楚地记得一次与开发人员在Sprint中期的讨论，他说：“提醒我一下，我们这次Sprint要达成的是什么？”

在一个没有充分澄清产品待办事项的漫长的Sprint中，这个开发人员完全忘记了团队在冲刺中追求的任何大目标。

Sprint目标的作用是持续对该目标的聚焦。我记得我回答他的问题时说，“增加停留在搜索结果页上的平均时间”，这是Sprint的目标。

在Scrum的早期，Sprint目标通常用于评估Sprint是否满足Sprint的目标，判断Sprint是否成功。如果没有达到Sprint目标，Sprint就没有成功。

以这种方式看待Sprint是不完整的。在一句话或两句话的Sprint目标之外，通常需要做一些其他重要的事情。

将整个Sprint提炼为一个目标与我在工作日志系统里遇到的问题相同，在系统里我要列出每天需要完成的三件最重要的事情。还房款并不是我需要做的最重要的事情，但它又不得不做。那我是应该推迟还房贷直到我因为欠钱被赶出房子的那一天？亦或是这会是那天最重要的事情？

Sprint是团队需要完成的复杂工作集合；这个工作集合不可能总是封装成一个单一的目标。

转为关注产品待办事项

想象一下，一个高尔夫球手正在某个地方打一个标准洞。这位高尔夫球手的目标是在四次击球中把球打进洞。第一个将是从发球台发球。第二种是近距离击球，球手试图将球落在果岭上。下一步，球员推杆，希望球能进到洞里。但球手可能需要第二次推杆，那就是总共四杆。

在整个过程中，高尔夫球手的注意力都集中在一个目标，就是尽可能少的挥杆就能把球打进洞中。这一目标是通过一系列的任务来实现的——一次远距离击球，一次良好的近距离击球，以及一次成功的第一次或第二次推杆。

我认为类似的方法也适用于Scrum团队。高尔夫球手可以专注于成功地完成每一次击球，因为他知道，每次击球都将达到在该洞取得好成绩的预期效果。Scrum团队也应该能够做到这一点：专注于工作、Sprint待办列表，这些都能将导致Sprint的成功。

这种方法还适合那些需要处理无法将多个工作包含在单个Sprint目标中的团队，就像之前的数字化代理商一样。

正如高尔夫球手的每一次挥杆都可以被视为洞内整体得分的前置指标一样，团队可以将完成单个Sprint待办列表视为成功实现某个非正式目标的前置指标。

我的建议

如果Sprint目标对您的团队有效，那么您应该继续使用它。如果你从团队中听到“我们这次Sprint的到底要完成什么？”的话，Sprint目标会有所帮助。如果您是Scrum新手，您绝对应该尝试为几个Sprint编写Sprint目标。

但是，如果当你一直尝试使用Sprint目标，而对团队并不奏效时，就不需要再继续使用了，把这些都当作有着宝贵价值的尝试吧。

附上原文：

https://www.mountaingoatsoftware.com/blog/why-i-dont-emphasize-sprint-goals?utm_source=drip&utm_medium=email&utm_campaign=Why+I+Don%E2%80%99t+Emphasize+Sprint+Goals

Why I Don’t Emphasize Sprint Goals

I admit to feeling some ambivalence toward Scrum’s Sprint goal. I coach teams to try creating Sprint goals, but I also inform them that not every team benefits from a Sprint goal.

Blasphemy? Perhaps.

The Sprint goal is defined as the single objective for the Sprint.

I love that. I spend a lot of time advising organizations to narrow their focus regarding what they will achieve, whether it be for a year, a quarter, or even a single Sprint. It’s all too common for an organization or team to select a goal the way I load my plate at a buffet: a little of this, a little of that, some of the other…

But sometimes a Sprint cannot be focused on a single objective. Some teams simply have multiple things that need to get done. For example, consider a digital agency. A team there could be simultaneously building a new website for one client, doing some mid-sized enhancements for a second client, and making small bug fixes or edits for five additional clients.

How should their Sprint goal be written? Should the goal focus on the new website, which will consume the most work during the Sprint? Or should it focus on the small edits if those are for the company’s most important client?

Some teams merge all that into one goal with something like, “Finish the seven user stories we committed to.”

That doesn’t help. It doesn’t provide the clarity a good goal gives, and it’s too broad to focus the team on a single objective. Teams who write “finish the user stories we committed to” and consider that a Sprint goal have effectively given up on Sprint goals.

The Goal of the Sprint Goal

The goal of the Sprint goal is to focus the team’s attention on what most needs to be achieved. I remember how vital this was in the late 1990s, the early days of Scrum. Back then all teams did four-week Sprints, no one did what we today call backlog refinement, and Extreme Programming hadn’t yet introduced the world to user stories.

Back then, teams would lose sight of what they were working on. I can clearly remember a mid-Sprint discussion with a developer who said, “Remind me: what is it we’re trying to get done this Sprint?”

In a long Sprint with inadequately expressed product backlog items, this developer had quite literally forgotten whatever big goal the team was pursuing that Sprint.

The Sprint goal served to restore focus to that goal. I remember answering his question with, “increasing the average time spent on the search results screen,” which was the Sprint goal.

In the early days of Scrum, Sprint goals were usually used to evaluate the Sprint—meet the Sprint goal and the Sprint was a success. Don’t achieve the Sprint goal and the Sprint wasn’t a success.

Looking at a Sprint this way is incomplete. There are often important things that need to be done that are outside a one- or two-sentence Sprint goal.

Distilling an entire Sprint to one goal has the same problems I have with to-do and personal productivity systems that tell me to make a list of the three most important things I need to accomplish each day. Paying my mortgage is rarely the most important thing I need to do on a given day, but it does need to be done. Should I really put off paying my mortgage until the day I’m to be evicted for non-payment, at which point it truly is the most important thing that day?

A Sprint is a complicated collection of work a team needs to accomplish; that work cannot always be encapsulated within a single goal.

Focusing Instead on Product Backlog Items

Imagine a golfer playing a typical hole somewhere right now. The golfer has the goal of getting the ball in the cup in four shots. The first will be a drive from the tee. The second will be an approach shot, in which the player attempts to land the ball on the green. Next, the player will putt the ball, hoping to make it into the cup. But the player will likely need a second putt, which makes four shots overall.

Throughout this, the golfer is focused on a goal—get the ball in the cup in as few shots as possible. That goal is accomplished through a sequence of tasks—a long drive, a good approach shot, and a successful first or second putt.

I think a similar approach is appropriate for Scrum teams. The golfer can focus on successfully making each shot, knowing the shots will add up to the desired result of a good score on that hole. Scrum teams should be able to do the same: focus on the work, the Sprint backlog items, that lead to a successful Sprint.

This approach also supports a team that needs to work on things that cannot be contained within a single Sprint goal, as was the case with the digital agency earlier.

In the same way that each of a golfer’s shots can be viewed as leading indicators of a good score on the hole overall, a team can see completing individual Sprint backlog items as leading indicators of success toward achieving some informal goal.

My Recommendation

If Sprint goals work for your team, by all means you should continue using them. If you hear “What is it we’re trying to get done this Sprint?” from the team, Sprint goals can help. And if you’re new to Scrum, you should absolutely try writing Sprint goals for a few Sprints.

But, if you’ve tried writing Sprint goals and they just didn’t work for your team, then consider your effort a useful experiment, and proceed without them.

*点击下方 阅读原文 可直达作者原文地址。