我试图更好地理解用户故事的 INVEST 属性。例如考虑这两个用户故事：
咖啡机是可编程的，可以定义不同种类的产品。产品在产品列表中具有唯一名称、价格和一些成分（指定数量），可在咖啡、牛奶、巧克力和糖之间进行选择。咖啡机使用户能够添加、修改或删除产品，并使用客户可用的产品列表创建配置。
用户可以选择产品并投入等于或大于产品价格的金额。如果金额大于价格，则咖啡机给用户找零。
在这两个故事中可以找到哪个 INVEST 属性？哪个不是？
从我的角度来看，我认为可能是这样的：
我对吗？最后你认为有可能按照 3C 的风格重写它们吗？
在我看来，一个好的团队合作的用户故事应该以“INVEST”格式完成。但是，为了提醒用户故事的好处，它应该遵循 3C 的风格。如果用户故事没有卡片、对话和确认，它就失去了用户故事的意义。
在我的团队中，我们尝试使用“INVEST”（用户故事格式为/我想要/这样）来编写用户故事，然后我们将对此进行“对话”。在本次会议中，我们知道“卡片”是否处于良好状态或“INVEST”。然后，我们“确认”这张卡适合冲刺。
一些团队不专注于使用户故事成为“投资”或用户故事格式，因为他们专注于卡片的“对话”。因此，格式可以是团队同意的任何内容。
有时，您的团队会找出最适合他们的用户故事格式。它会自然发生。
所以，我认为这没有灵丹妙药。请记住，用户故事或项目（您想调用的任何名称）是您的团队同意并乐于使用它的东西。做出决定的不是一个人，而是团队。
您在尝试定义用户故事时强调了许多问题。
正如您所意识到的，让用户故事与所有 INVEST 原则相匹配有时会很棘手。这些原则的目标是瞄准，所以如果您不能全部匹配，请不要担心。
让用户故事真正独立通常是最难实现的原则。我建议将您的用户故事缩小到您的团队可以轻松估计的大小。随着故事变得越来越大，它们变得越来越难以估计，并且产生误解的可能性也越来越大。
团队经常将用户故事与规划扑克相结合，这是一种敏捷估算技术。这有助于了解何时需要进一步分解用户故事。例如，许多 Scrum 团队不会引入超过 13 分的故事，而是经常尝试将 13 分的故事分解为 8 分和 5 分。
3 C 提醒您在练习用户故事时什么是重要的。主要是对话和协作元素。这不是这样的格式。
如前所述，用户故事应定义为：
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 原则。只是不要忘记，定义用户故事并不是一项单独的活动。
希望这可以帮助。
PS 你关于用户故事的问题可能更适合pm.stackexchange.com。