就像《金发女孩与三只熊》中的故事一样，我们不希望产品待办列表中的项目包含太少或太多的细节，而是希望细节恰到好处。
用户故事的恰当细节水平
为了理解用户故事（或任何产品待办项）的恰当细节水平，可以考虑这么一个例子。
我刚刚下了一个超市配送订单。我的订单中包括五个苹果，我选择的是Honeycrisp苹果，并且准确无误地收到了。
我没有指定苹果的直径必须正好是三英寸，也没有指定苹果要结实、不发霉。
下订单时，我必须提供适当的细节，以确保我得到我想要的东西：苹果的品种和数量。
细节不足的问题
如果产品负责人编写的用户故事包含的细节太少，开发团队在制定Sprint计划时就没有足够的信息，无法理解要开发什么功能。这意味着：
团队将在Sprint期间花费宝贵的时间去问问题 团队成员可能会错误地开发某些东西 估算很有可能是不准确的 基于这些估算而对干系人或客户做出的承诺很可能是无法达成的
尽管这些问题可能很严重，但Scrum团队仍然需要小心，不要走极端地通过增加过度的细节来解决这些问题。
细节过多的问题
“用户故事写得过于详细” 一开始听起来可能像一个自相矛盾的说法，你不可能太富有、太瘦，或者在产品待办项上有太多细节。但事实上，在产品待办项中包含过多的细节是完全可能的。
当故事细节过多时，花在添加非必要的细节上的时间和金钱都是一种浪费。如果要求超市配送员一定要找到直径三英寸的苹果，这对我和他来说都是浪费时间，除非在特殊情况下确实需要对苹果的直径有精确要求。
也许比浪费时间和金钱更糟糕的是，开发人员可能会因为过多的细节感觉受到人为约束。假设我向一位超市送货员提出以下要求：
买五个苹果
Honeycrisp品种
直径三英寸
结实的
没有淤斑
如果符合所有要求的苹果没有五个该怎么办？是否可以选择一个略大一点的？直径三英寸直径是最重要的吗？我是偏向于选择没有斑块的较大一点的苹果，还是大小刚好但有一个淤斑的苹果？
这些在买苹果的情况下可能看起来微不足道，但在开发产品时就不是这样了。当团队收到用户故事必须满足的冗长需求清单时，即使有更好的方法来开发功能，许多团队也会因为拒绝偏离清单上的任何要求而不予考虑。
迭代式获取用户故事的适当细节
我发现当团队从较少的细节开始时，他们更容易找到正确的细节水平。也许可以先在用户故事模板中填写最基本的产品功能和细节。
当团队从过多细节开始时，团队成员可能甚至不会注意到有问题。请记住，细节过多的一个重大问题是，在需要这些细节之前就浪费了时间用来收集。不过，团队成员可能没有注意到这一点，或不认为这是浪费。他们可能只是看到迭代顺利进行，很少有最后一刻的新发现干扰他们，并对这种细节水平感到满意。
然而，如果团队在开始时得到的细节太少，他们就会注意到由此造成的问题。团队成员很难在迭代内完成所有内容，有太多问题需要解决。他们可能感到在所知甚少的情况下被要求对一些工作进行估算。
因为这些都是有明显影响的实际问题，所以团队成员很清楚他们得到的细节太少。解决方法也显而易见：收集更多细节。
通过在启动时产品待办项上的细节不足，团队将能够迅速检视和调整，找到合适的细节水平。
适度的细节是什么样的？
当产品待办项包含适度的细节时，团队成员会觉得在迭代期间恰好勉强能完成待办项。他们会觉得已经提前确定了足够多的细节，但又不会太多，以至于迭代中的创造力被剥夺。
用户故事示例
必须提供唯一的电子邮件地址
必须指定强密码
可以通过Facebook帐户登录
经验1：并非所有事情都需要在开始前确定
经验2：过早添加过多细节有害无益
登录故事的另一个验收标准是用户可以通过 Facebook 账户登录。这是一个过早提供过多细节的例子。
在最初编写登录故事时，最好只说明用户可以通过社交媒体登录，而不是可以通过 Facebook 登录。在大多数情况下，没有理由事先确定 Facebook 是用户登录的唯一附加方式。
适度细节的乐趣
你的团队在控制适度的细节方面表现如何？从包含太少或太多细节的故事中你看到了哪些问题？你的团队采取了哪些措施来保持适当的故事细节？欢迎在评论区分享你的经验和观点。
注：部分图片来源于网络
原文地址：How Detailed Should a User Story Be? (mountaingoatsoftware.com)
关于作者
关于Scrum中文网
Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构，大规模敏捷SAFe官方机构SAI中国区金牌授权合作伙伴，和Scrum.org官方授权教育机构。
