要是问开发团队需求文档应该写成什么样，一千个团队可能有一千个答案。而产品经理在各种各样的模板的需求文档中疲于奔命，还不一定能让团队满意。那么对于实践敏捷开发模式的团队，产品经理该怎么写开发文档让团队满意呢？
答案很简单，只要符合下面两条就可以了：
在需求梳理会上，对于该需求，团队能给出故事点数并且这个故事点数的大小表示在一个“冲刺”中能够做完该需求
需求不在详细，而在于团队能明白
敏捷实践使用用户故事描述需求。虽然敏捷实践中对用户故事的格式提出了下面的要求，但是没有明确用户故事到底该写得多详细。合格的用户故事只有一个标准，团队能够明白这个用户故事的意思，知道该怎么做。敏捷更看重的的是沟通和交流，而不是文档。
用户故事的描述语言 As a user, I want to do something, so that I can achieve some goal.检验标准 Given some precondition When I do some action Then I expect some result
最终说明团队能不能明白用户故事的含义，有前文所述的两条决定。
给不出故事点数就不能纳入开发计划
在用户故事梳理会上，最佳实践之一是采用故事点数来评估需求的工作量大小。有关如何评估故事点数可以查看我的这篇文章：
敏捷技巧：怎么样才能让程序员在用户故事梳理会上不开小差？
在团队阅读了需求说明，产品经理也解释了需求中问题后，如果团队还是给不出点数，这说明团队没有明白需求或者不知道该如何实现需求。这样的需求只能被暂时搁置，产品经理需要重新修改需求描述，或者和相关的开发者讨论清楚以后在下次梳理会上再让团队评估，直到团队能给出点数为止。
在上面的过程中，团队通过故事点数实现了“需求准入”的目的，和一般的需求评审会相比，用户故事梳理会有明确的输出结果。一般来说，产品经理经过几次这样的会议就能和团队达成默契，明白什么样的需求描述和标准能被团队接受。
用户故事的点数应该能在一个“冲刺”中完成
在敏捷实践中，团队通常会设定一个点数表示某个用户故事能在一个“冲刺”中刚好能被做完。一般来说 13 点被设置为了这样一个点数。
如果某个用户故事的点数超过了 13 点，这个用户故事就应该被拆分成较小的用户故事。能在一个“冲刺”中能完成的用户故事才能作为“冲刺”计划的候选用户故事，因为每个“冲刺”都需要完成一定数量的用户故事作为“增量”交付内容。在一个“冲刺”中做不完就可能导致这个“冲刺”没有可交付的内容。
结论
敏捷开发通过让团队对产品经理书写的用户故事“打分”，实现了需求准入的目的。产品经理不用拘泥于文档的格式，只要能在需求梳理会上让团队为自己拟定的用户故事打出合格的用户故事点数，需求文档就算过关。相比传统的需求文档和评审会议，敏捷实践通过团队交流和合作提高了需求产出的效率。
更多文章
敏捷实践：开站会只问昨天做了什么？今天准备做什么就行了吗？ 哪种敏捷实践能让“老板”最快看到团队敏捷转型的效果？ 敏捷实战：以疫情“动态清零”为例看如何使用“影响地图 (Impact Mapping)”为敏捷团队创建工作计划？ 敏捷技巧：为什么说产品经理不能只按照优先级决定每个迭代的交付内容？ 为什么说“事件风暴”是“产品经理”连接“行业专家”和“开发人员”的利器？ 敏捷技巧：怎么样才能让程序员在用户故事梳理会上不开小差？ 长假之后，Scrum团队应该修改Sprint的结束时间吗？ 精益和敏捷的较量：你知道敏捷开发有 Scrum 和 Kanban 两种管理模式吗？
相关文章
您阅读本篇文章共花了：
发表评论