更有成效的整容会议

Question

我正在寻找一种方法来使我们的Scrum修饰会话更有效率。目前，我们似乎需要很长时间才能创建用户故事和接受标准。在一个小时的会议中，我们通常会有2-4个用户故事，包括验收标准。到达那里的过程很痛苦，需要很长时间。

参与者包括来自Dev + Architecture、QA、BA、Customer、Product (me)、可用性的成员。

我看到的问题是，我们进行了很好的讨论，但故事的措辞过程--尤其是接受标准--需要相当长的时间。

因为我们是一个分布式团队，所以我们必须通过电话、屏幕共享和协作编辑环境来完成这个任务。这肯定会影响生产力，因为我们不在同一个房间，但我仍然觉得我们的过程可以改进。

一些问题：

• 有多少故事，你通常结束后，一次修饰会议？
• 您是创建验收标准作为修饰期次的一部分，还是在外部创建？
• 您是如何创建用户故事的，以及什么过程适合您？

Answer 1

问团队！

好吧，我的答案很短，所以让我解释一下。团队对您的技术、问题、文化和产品的了解比这里的任何人都要好；因此，他们是最好的答案。这是一个典型的话题，你应该在回顾和不断改进的精神中提出-检查和适应。不断调整和尝试，直到事情变得更好。

因此，在你的下一个复古，提出它和检查问题，并承认它是无效的。看看适应的机会，然后去做。

一些技巧(但不是作为Scrum大师)

• Scrum推荐你10%的能力用于梳妆。
• 没有规定每个人都应该在会议上这样做。
• 举行会议以管理例外情况或需要进行更正式讨论的领域
• 试着打扮一下
• 记住，故事是沟通的占位符，而不是契约
• 获取核心验收标准，在计划会议和sprint中构建其余部分。

有多少故事，你通常结束后，一次修饰会议？

足以应付接下来的两次短跑，保持公正及时的态度。

您是创建验收标准作为修饰期次的一部分，还是在外部创建？

无论是与PO的正式会话中的关键业务接受标准，还是会话之外的功能会话中的关键业务验收标准。在整个过程中，甚至在sprint计划和sprint中，都应该添加验收标准。避免把他们当作合同对待。

您是如何创建用户故事的，以及什么过程适合您？

我通常从满足业务需求的业务焦点故事开始。在修饰过程中，我们使用动作/动词或用例模型将其分解为功能性故事。这些都可以写成故事。在一个典型的1小时的会议中，你可以很容易地头脑风暴50多个需求在一个高水平。当实现sprint越来越接近时，您可以将它们分解为投资故事；但是要在功能级别进行报告。