用户故事 应该很小。
这就是* S *在 ‘Invest’ acronym;记住和评估什么才是好的用户故事的一种方式。
不能太小。但是肯定不会太大。那么，一个好的用户故事合适的大小是多少？
首先，让’让事情变得直截了当。这个说法有些误导。更准确地说，应为： “在您计划将其包含在Sprint中时，用户故事应该很小”.
因为直到您进入Sprint Planning– until you’准备在下一次迭代中包含该功能–用户故事可能很大。实际上，它们可能很大。 ！它’对于进一步深入的用户故事，这是完全合理的 产品积压 相当大且模糊。
只要它们在它之前分解’是时候对他们进行研究了，’很好。它们仍然是有效的占位符。所以’可以在待办事项中进一步添加用户故事，例如： “作为用户，我需要一个新系统，因为旧系统不再满足我的需求”.
这些重要的用户故事被称为 史诗.
无论如何，回到了要点。什么 ’准备好要开发的用户故事时，大小合适吗？
让’s take my recent 用户故事的示例。可能是： “作为用户，我想在线注册，登录和管理我的详细信息”. 但我认为’太大而无法成为一个好的用户故事。也许它像史诗般开始了这样的生活，积压得更远。那就好了。但是在进行Sprint计划时，应该分解这样的故事。
所以让’s say it’分为3个故事：注册，登录和管理详细信息。登录故事可能会进一步细分为另外三个故事，例如：登录，忘记密码，记住我。我认为’一个不错的大小。故事非常集中。小。但是，每个故事仍然可以发挥作用并实现自己的目的。和他们’re still fairly 独立.
现在让’s说登录故事进一步细分。例如： “作为用户，我想输入我的用户名”, “作为用户，我想输入密码”, “作为用户，我想按登录按钮”, “作为用户，我想在登录失败时得到清晰的错误消息”等等，然后我’d say it’太过分了。这些故事太详细了。在这个级别上，即使是一个很小的项目也将最终包含数百个故事，并且很难管理。
最后，那里’真的没有对与错–您需要做适合您和您的团队的事情。尽管如此，我希望我的评论能提供一些有用的指导，即使它’只是您的团队辩论的起点…
凯莉
