在敏捷(混乱)环境中，如何让产品管理人员创建足够小的待办事项或者故事，而无需他们进行所有设计，这不是他们的专长吗？换句话说，如何在敏捷开发中将(业务需求)和(设计)方式分开？

解决方案

回答

使用scrum时，产品管理人员应该是一个人：产品所有者。

我们想要做的是在sprint计划期间完成的，整个团队(产品所有者，scrummaster，开发人员)应该在这里。

产品所有者应将其定义为用户故事。用户故事应该是高级的，因此限制产品所有者以一句话来表达业务需求就可以解决问题。

e.g.
  As a StackOverflow user, I would like to see my reputation

冲刺计划的目标之一是确定在冲刺过程中应完成的故事。因此，当产品负责人选择故事时，团队可以对其进行细分，简要讨论设计(如何)并进行估算。

简而言之，产品所有者应做什么，团队应如何做。
如果向产品负责人清楚地说明了此过程，则他不会尝试设计所有东西。如果他仍然尝试，scrummaster将会阻止他。

回答

不要忘记，应使用权重系统(质数，斐波那契等)对产品待办事项进行重要性排序，以便如果待办事项中具有相似重要性的项目(即2个项目的重要性权重为21)，则理论上应该同时尝试并在13s和8s之前插入sprint。

回答

我们必须做的第一件事就是教会产品管理人员扮演产品负责人的角色，这是造成Scrum Projects大量失败的原因。我们必须向他证明他负责该项目的投资回报率，并且为此，他负责按优先级排列故事/索引/业务需求/功能或者我们正在使用的用于编排产品待办事项的任何事项的优先级有价值的项目具有更高的优先级。

我赞成使用用户故事作为产品待办事项列表，然后在sprint计划中，将较小的任务分解为组成sprint待办事项的故事。

在编写或者帮助PO编写用户故事时，我们应该始终牢记的是，故事应该是INVEST。独立，可协商，对客户有价值，可评估，小巧且可测试。

我认为一开始使用模板波纹管可能有助于使PO专注于业务目标：

"As a - type of user -, I want -some goal- so that -some reason-."

一个故事示例是"作为stackoverflow用户，我想对答案进行投票，以便可以轻松找到最有价值的答案。"

不要忘记为Sprint Backlog的每个故事编写PO或者定义验收测试，因为它可以用作确定故事是否得到充分实施的基本标准。

对于上面的示例，两个可能的验收测试是：

"测试投票答案"

"测试以否决答案"

通过此故事和两次验收测试，团队知道堆栈溢出用户可以对答案进行投票，并且可以通过完成故事状态进行更新，因此系统必须允许用户对答案进行上下投票，而不会引发异常。

回答

在积压(重新)估计(优先级划分之后)中，团队应该进行建模，以了解用户故事的完整范围并能够准确地估计复杂性。这并不是建模的全部范围(团队可能会做更多的工作来进行开发)，但这是一个很好的起点，并且可以利用周围的客户/产品负责人来回答问题接着。

因此，最终的讨论将与产品负责人一起将他们的需求分解为有意义和适当的粒度。