我在之前的帖子里曾写过对sprint进行编号除了用数字之外还有其他选择吗？今天这篇帖子我来说说一些团队给sprint编号时使用的的一个非常特殊的数字—0。
Sprint0这个概念在有些团队中变得越来越常见，所以我们很有必要来思考一下它到底是不是个好的提议。
首先，假设我们赞同sprint0存在的必要性。Sprint0通常被声明为必须的，因为在scrum项目开始前有许多事情要完成。例如，需要组建一个团队。这可能涉及到要招聘或调拨一些人到这个项目来。有时，也需要采购一些硬件或至少要安装一些软件。许多项目组也在努力说服别人，说他们需要在sprint0中编写初始backlog（即使仅仅是高级别的）。
设置spint0的一个最大的问题是，它产生了例外—有些sprint或sprint类型具有与众不同的特性。比如，在sprint结束时能得到潜在的可交付的成果这一scrum宗旨就被摒弃了。毕竟，如果sprint的目标是组建团队，那么他们怎么能得到潜在的可交付的东西呢？
我发现，很多能被拿来争取sprint0的理由实际上和被我称作项目前的项目是出于同一考虑。通常，在一个开发项目开始之前会有另外一个项目来决定是否确实需要这个开发项目；在一个公司开始一个大的革新之前，有些人也不得不考虑是否的确需要启动这项革新。
做这些决定的工作过程可以被看作是一个项目。
考虑到scrum是一个很好的通用的目标项目管理框架，它能够被用来管理项目前的项目所做的工作。在项目前的项目里，初期的团队成员（可能只有一个未来的项目所有者）可以创建一个初始的产品backlog，寻找或招聘组员，安装技术相关的环境等等。
我发现把这部分工作归到一个单独的项目内很有用，因为不难想象这部分的工作比sprint0这一个特殊的sprint要花费更多的时间。而且，一个使用sprint0的团队怎样称呼他们的第2个sprint呢，假如他们需要另外一个sprint来用来调整这个特殊类型的sprint的话？叫做sprint0.5？
综上，有2点需要注意：
尽可能的保持轻量级的“项目前的项目”。大多数开发项目在他们开始前并不需要一个这样的项目。
严格遵守scrum的宗旨。一个参加了项目前的项目的团队将无法产出潜在可交付产品。这也没错，但是，请您思考并理解为什么产出潜在可交付物是scrum的一个核心宗旨，并且请以一种好的方式应用在项目前的项目中。
我将在下周的帖子中续写这个话题—在项目前的项目中遵守scrum的宗旨
（本文经授权翻译及转载，不得复制。原文来自：http://www.mountaingoatsoftware.com/blog/sprint-zero-a-good-idea-or-not）
