作者：Mike Cohn
译者：李洁（Jerry Li）
原始链接：
https://www.mountaingoatsoftware.com/blog/six-times-two-plus-one-equals-a-good-project-cadence
在上个月的发文中，我阐述了一切事情都应该在Sprint中开展的观点。诸如设计、缺陷修复或其他任何事情，团队也都应当在Sprint中进行，不应当存在任何“游离于Sprint之外的事情”。但是，在本文中，我想分享一个可能的例外情况。
多年以来，我一直在干着一件叫做“6×2 + 1”的事情——这代表着，先做6个为期2周的Sprint，再进行1个为期1周的Sprint。这个想法大约产生于多年前作为公司软件开发副总裁的我与兼任公司市场副总裁的CEO开会的时候。
当时我们正在讨论下个季度我的研发团队们将要交付什么功能。市场副总裁问我，下个季度你们会有6个还是7个Sprint？他知道我们在开展为期2周的Sprint，并且我们总是基于季度的开始时间来确定开展6个还是7个Sprint。
为了回答他的问题，我开始按照每个Sprint在周五结束来计算Sprint数量：10月8日、10月22日、11月5日、11月19日，我就这样数着。。。。。。然后，我得搞清楚11月有30天还是31天了。当我用掰着手指算有多少天时，我决定从那一刻开始，每个季度固定安排6个冲刺。
但是6个为期2周的冲刺，会使我在季度中多出1周的时间。该怎么办呢？我决定把那周时间交给团队——他们可以做任何自己想做的事情。团队不是一直都在争取更多时间进行重构或做任何他们想要进行的技术性工作，却又不能说服其Product Owner吗？这样一来，他们每个季度就都有一个星期可以实施自己想做的事情了。
把这个想法兜售给Product Owner并不难。我告诉他们，在那一周内，团队仍将为其产品增值，只是将由团队来决定什么是最有价值的事情而已。为了使这个想法能真正落实到产Product Owner身上，我告诉他们，每季度将有一个星期时间，团队不再需要他们，从而使得他们能将自己释放出来，进行更远大的产品思考，和研究自己认为需要的东西。
这真是个绝妙的主意！我告诉团队我是为了他们而作此决定的。同时，我也告诉Product Owner们我也是为了他们而作此决定的。虽然我做此决定的初衷，只是为了能让自己不用匆忙地花时间去计算日期。
这还进一步带来了一个好处：每个季度交给团队的这一周时间，通常都不在考虑发布日期的计划时间范围内。而每当一个项目遇到麻烦并且不能按计划日期完成时，我们都可以将这第13周也用作正常的Sprint部分。然后，我们会将第17周或任何随后的某一周还给团队。
团队并不在乎他们拿到的是第13周还是第17周。他们只关心自己是否能在某个时刻拿到每季度一次的1周时间，并且非常期待“我们的一周时光”。
将此与上个月的发文联系起来：通过我实行的“6×2 + 1”工作方式，某些团队确实将第13周当成了Sprint之外的时间。大多数团队会在那一周继续运行Scrum。他们将进行非常简单的计划和评审会议。大多数人甚至会每天继续召开每日站会，虽然只是为了听听彼此在做些什么。
但是，也有些团队会在那一周完全不运行Scrum。我也同意他们这么做，尽管我承认自己更倾向于进行一个会议非常轻量（简短）的、为期1周的Sprint。但是，这一次，我确实将某些工作当成了“Sprint之外”的事情。
