要是问开发团队需求文档应该写成什么样，一千个团队可能有一千个答案。而产品经理在各种各样的模板的需求文档中疲于奔命，还不一定能让团队满意。那么对于实践敏捷开发模式的团队，产品经理该怎么写开发文档让团队满意呢？
答案很简单，只要符合下面两条就可以了：
敏捷实践使用用户故事描述需求。虽然敏捷实践中对用户故事的格式提出了下面的要求，但是没有明确用户故事到底该写得多详细。合格的用户故事只有一个标准，团队能够明白这个用户故事的意思，知道该怎么做。敏捷更看重的的是沟通和交流，而不是文档。
最终说明团队能不能明白用户故事的含义，有前文所述的两条决定。
在用户故事梳理会上，最佳实践之一是采用故事点数来评估需求的工作量大小。有关如何评估故事点数可以查看我的这篇文章：
在团队阅读了需求说明，产品经理也解释了需求中问题后，如果团队还是给不出点数，这说明团队没有明白需求或者不知道该如何实现需求。这样的需求只能被暂时搁置，产品经理需要重新修改需求描述，或者和相关的开发者讨论清楚以后在下次梳理会上再让团队评估，直到团队能给出点数为止。
在上面的过程中，团队通过故事点数实现了“需求准入”的目的，和一般的需求评审会相比，用户故事梳理会有明确的输出结果。一般来说，产品经理经过几次这样的会议就能和团队达成默契，明白什么样的需求描述和标准能被团队接受。
在敏捷实践中，团队通常会设定一个点数表示某个用户故事能在一个“冲刺”中刚好能被做完。一般来说 13 点被设置为了这样一个点数。
如果某个用户故事的点数超过了 13 点，这个用户故事就应该被拆分成较小的用户故事。能在一个“冲刺”中能完成的用户故事才能作为“冲刺”计划的候选用户故事，因为每个“冲刺”都需要完成一定数量的用户故事作为“增量”交付内容。在一个“冲刺”中做不完就可能导致这个“冲刺”没有可交付的内容。
敏捷开发通过让团队对产品经理书写的用户故事“打分”，实现了需求准入的目的。产品经理不用拘泥于文档的格式，只要能在需求梳理会上让团队为自己拟定的用户故事打出合格的用户故事点数，需求文档就算过关。相比传统的需求文档和评审会议，敏捷实践通过团队交流和合作提高了需求产出的效率。