我试图更好地理解用户故事的INVEST属性。 例如，考虑这两个用户故事：
咖啡机是可编程的，可以定义不同种类的产品。 产品在产品清单中有一个独特的名称，价格和一些成分（指定数量）在咖啡，牛奶，巧克力和糖之间进行选择。咖啡机使用户能够添加，修改或删除产品，并创建包含客户可用产品列表的配置。
用户可以选择产品并插入等于或大于产品价格的金额。如果金额大于价格，咖啡机会向用户提供更改。
在这两个可以找到INVEST属性的故事中？不是吗？
从我的观点来看，这就是我的想法：
我是对的吗？ 最后你认为可以按照3 C的风格重写它们吗？
答案 0 :(得分：4)
在我看来，团队合作的好用户故事应该以“INVEST”格式完成。但是，为了提醒用户故事的好处，它应该遵循3 C的风格。如果用户故事没有卡片，对话和确认，则会失去用户故事点。
在我的团队中，我们尝试使用“INVEST”编写用户故事（用户故事格式为/我想要/那样），然后我们就此进行“对话”。在本次会议期间，我们知道“卡片”处于良好状态或“投资”与否。然后，我们“确认”该卡有利于冲刺。
有些团队并不专注于将用户故事设为“投资”或用户故事格式，因为他们专注于卡片的“对话”。因此，格式可以是团队同意的任何内容。
您的团队会不时地找出最适合他们的用户故事格式。它会自然而然地发生。
所以，我认为这没有灵丹妙药。请记住，用户故事或项目（您想要调用的任何名称）是您的团队同意并且使用它很舒服的事情。做出决定不仅取决于一个人，而是团队。
答案 1 :(得分：2)
您已经突出了尝试定义用户故事的许多问题。
正如您所知，让用户故事与所有INVEST原则相匹配有时会很棘手。这些原则的目标是瞄准，所以如果你不能将它们全部匹配，不要担心。
让用户故事真正独立通常是最难理解的原则。我建议您将用户故事缩小到足够小的尺寸，以便您的团队能够轻松估算。随着故事变得越来越大，他们的指数估计会越来越难以及误解的可能性更大。
团队经常将用户故事与计划扑克相结合，这是一种敏捷估算技术。这有助于了解用户故事何时需要进一步细分。例如，许多Scrum团队不会引入高于13分的故事，并且经常试图将13分故事分解为8分和5分。
3 C用于提醒您在练习用户故事时的重要性。主要是会话和协作元素。这不是一种格式。
正如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。