为了做出更好的估算，您可以列出需要制作的屏幕和技术组件的清单。但要小心：不要描述太多技术细节，除非涉及复杂的公式或类似的东西。为开发人员提供展示创造力和/或创造力的空间。开发人员可以轻松地相互协调如何编译列表、如何计算数字以及如何调用无数个普通组件。
提示：让 Scrum 团队创建一份需要描述内容的清单。该清单也称为“就绪定义”（不要与“完成定义”混淆）。开发团队可以很好地决定他们需要什么规格。
请务必：说清楚、简洁！当然，所有必要的东西都应该包括在内，但任何额外的东西通常都是噪音。用户故事是一种惯例，如果您不将用户故事描述为用户故事，那么它就不是用户故事。全球接受的符号是：作为 [角色] 我想 奥地利数字数据 要 [功能]，以便我可以 [动机]。
例如：作为网站的匿名访问者，我希望能够搜索产品目录，以便快速找到我正在寻找的产品。
这用一句话描述了用户故事的如何和为什么。对于客户来说，动机部分通常看起来合乎逻辑，但对于开发人员和测试人员来说，它不必那么明显。对于他们来说，这是非常有价值的信息，因为它让他们深入了解用户及其需求。
当编写用户故事时，您需要仔细考虑谁真正想要某些东西。最终用户不想要模块化的网站或一栏广告：这是网站架构师和所有者想要的。如果没有角色与某些事物相联系，那么就没有理由创建用户故事，而且就我而言，它可以被无情地省略。
每个用户故事至少有一个、通常有多个场景。最好以双方同意的、 SMART 描述的符号来写下这些内容。这听起来很有道理，但对许多人来说却是一个挑战。当使用“快速”，“很多”或“易于使用”等词语时要警惕：这些词语可能会引发开发人员的过敏反应。
一个相当简单的符号的例子：给定 [起点]。如果 [行动]，那么 [预期结果]。