在敏捷（scrum）环境中，如何让产品管理创建足够小的积压项目或故事而不让他们完成所有设计，这不是他们的专长？换句话说，您如何将敏捷开发中的（业务需求）与（设计）分开？
答案 0 :(得分：3)
您必须做的第一件事就是教您的产品管理部门扮演产品负责人角色，这是导致大量Scrum项目失败的原因。您必须向他表明他负责项目的投资回报率，为此，他负责确定故事/ itens /业务需求/功能的优先级，或者以最大的方式构建产品积压的任何内容有价值的itens具有更高的优先级。
我赞成将用户故事用作产品积压，然后在sprint规划中打破选择的故事组成sprint积压的较小任务。
在撰写或帮助您的PO编写时，您应始终记住的是，您的用户故事是故事应该是INVEST。 我 ndependent， N egotiable， V 可供客户使用， E 可以强化， S 商场和 T estable。
我认为在开始时使用下面的模板可能有助于保持PO专注于业务目标：
“作为一种用户 - 我想 - 一些目标 - 所以 - 某些原因 - 。”
一个故事示例是“作为stackoverflow用户，我想对答案进行投票，以便能够轻松找到最有价值的答案。”
不要忘记为您的Sprint Backlog的每个故事写PO或定义验收测试，因为它可以用作确定故事是否完全实现的基本标准。
对于上面的例子，两种可能的验收测试是：
“测试投票答案”
“测试以回答答案”
通过这个故事和两个验收测试，团队知道stackoverflow用户可以对答案进行投票并更新故事状态做完成，系统必须允许用户在不丢弃的情况下上下回答答案异常。
答案 1 :(得分：2)
使用scrum，产品管理应该是一个人：产品所有者。
您想要做的是在 sprint计划期间完成，整个团队（产品所有者，scrummaster，开发人员）应该在场。
产品所有者应将 定义为用户故事。用户故事应该是高级别的，限制您的产品所有者表达业务要求一句话故事应该做的伎俩。
e.g。 作为StackOverflow用户，我希望看到我的声誉
sprint计划的目标之一是确定sprint期间应该完成的故事。因此，当产品所有者选择故事时，团队可以对其进行细分，简要介绍设计（如何）并估算它们。
简而言之，产品所有者应该完成 ，团队的如何。 如果向产品所有者明确说明了此过程，他将不会尝试设计所有内容。如果他无论如何都会尝试，那么scrummaster会阻止他。
答案 2 :(得分：0)
不要忘记产品积压项目应按重要性排序，使用加权系统（素数，斐波纳契，......），这样如果您的积压中的项目具有相似的重要性（即2重量为21的项目，那么它们理论上应该尝试并在13s和8s之前插入冲刺。
答案 3 :(得分：0)
在积压（重新）评估期间（优先级划分后），团队应该进行建模，以便了解用户故事的全部范围，并能够准确估计复杂性。这不是可能发生的建模的全部范围（团队可能会做更多的开发），但它是一个很好的起点，并且能够利用周围的客户/产品负责人回答问题然后。
因此，最终的讨论将帮助您与产品负责人合作，将他们的需求分解为有意义且合适的粒度。