Scrum（通常）强烈建议 PO 不应该单独编写故事，而应与团队成员一起编写。
编写用户是一种协作练习。（来源）
下面所描述的（后端，前端细节）比单独写故事的 PO 更糟糕，更糟糕。PM 不应参与这些技术决策：
产品负责人如何为团队编写/分解用户故事？
你可以在更高的层次上编写它们，然后给开发人员/测试人员写信，把那个单一的用户故事分解成子任务来处理它的所有部分。
今天，我们已经养成了编写用户故事并将它们分解为前端、后端等的习惯……对我来说，这并不理想，因为开发人员可能会做得更好，只要根据需求分解它就会。
在一个理想的世界里，我可能会写一个单一的用户故事，他们会分解它，或者我们会根据需要一起分解它。然而，我们的团队非常小，而且我们的员工工作时间也不一样，所以很难让每个人都在电话中讨论一个用户故事，更不用说为每个用户故事都这样做了。
如何实现共同讨论？
设置一个时间框并确保您有空，并让您的团队成员异步讨论它。您的工作是提出业务需求（WHY），而您的团队则发现 HOW。不过，它不需要在一次会议中发生。
此外，您是否在整个 sprint 中不断进行改进，以使积压工作保持良好状态？在下一个 sprint 计划之前，您应该讨论几个 sprint 的精炼内容。