我试图更好地理解用户故事的 INVEST 属性。 例如，考虑以下两个用户故事：
咖啡机是可编程的，可以定义不同种类的产品。 产品在产品列表中具有唯一名称、价格和一些成分（指定数量），可在咖啡、牛奶、巧克力和糖之间进行选择。咖啡机使用户能够添加、修改或删除产品，并使用可供客户使用的产品列表创建配置。
用户可以选择产品并投入等于或大于产品价格的金额。如果金额大于价格，咖啡机就会给用户找零。
在这两个故事中可以找到哪个 INVEST 属性？哪个不是？
从我的角度来看，我认为可能是这样的：
我说的对吗？ 最后你认为有可能按照 3C 的风格重写它们吗？
【问题讨论】：
标签： extreme-programming user-stories
在我看来，一个可供团队合作的优秀用户故事应该以“INVEST”格式完成。但是，为了提醒用户故事的好处，它应该遵循 3C 的风格。如果用户故事没有卡片、对话和确认，就失去了用户故事的意义。
在我的团队中，我们尝试使用“INVEST”来编写用户故事（用户故事格式为/我想要/这样），然后我们将对此进行“对话”。在本次会议中，我们知道这张“牌”是否完好或“INVEST”。然后，我们“确认”这张卡适合冲刺。
有些团队并不专注于让用户故事成为“投资”或用户故事格式，因为他们专注于卡片的“对话”。因此，格式可以是团队同意的任何内容。
您的团队会不时找出最适合他们的用户故事格式。它会自然而然地发生。
所以，我认为这没有灵丹妙药。请记住，用户故事或项目（您想调用的任何名称）是您的团队同意并乐于使用它的东西。做出决定的不是一个人，而是团队。
【讨论】：
您在尝试定义用户故事时强调了许多问题。
如您所知，让用户故事与所有 INVEST 原则相匹配有时会很棘手。这些原则的目标是要达到的目标，所以如果您不能全部匹配，请不要担心。
让用户故事真正独立通常是最难原则的。我建议将您的用户故事缩小到您的团队可以轻松估计的大小。随着故事变得越来越大，它们的估计难度会呈指数级增长，并且产生误解的可能性也越来越大。
团队经常将用户故事与规划扑克相结合，这是一种敏捷估算技术。这有助于了解何时需要进一步分解用户故事。例如，许多 Scrum 团队不会引入超过 13 分的故事，而是经常尝试将 13 分的故事分解为 8 和 5 分。
3C 提醒您在练习用户故事时什么是重要的。主要是对话和协作元素。这不是这样的格式。
正如previously 解释的那样，用户故事应定义为；
As a (role) - This can be an end user or a business proxy
I want - A description of what need to be done
So that - the definition of the value
然后您应该使用验收标准来定义内部运作。业务规则等
通过练习这种格式，您的用户故事将更符合 INVEST 原则。只是不要忘记，定义用户故事不是一项单独的活动。
希望这会有所帮助。
P.S 你关于用户故事的问题可能更适合pm.stackexchange.com。
【讨论】：