在敏捷/ scrum用户故事中,有多少细节就足够了？

Question

足够的细节就足够了通常的反应.

在我们目前忙于的项目上(这是不完整的并且没有任何brs /文档/用户故事移交给我们,我们得到的故事如下:

作为产品负责人,我需要开发人员测试XXX工作流程,以使其正常工作.

和

作为产品负责人,我需要开发人员测试YYY工作流程,以使其正常工作.

没有说明"正确"的含义.

在询问更多细节时,我们会被告知你要求太多细节,因为这是敏捷的,所以后期冲刺期间(2周冲刺)的要求会变得更清晰,你不应该担心当时的细节,而是只是让故事在"娃娃头发"中给予重量并且不再困难.做个大人物.不要担心细节.

这是敏捷应该是什么样的？

Answer 1

在询问更多细节时,我们会被告知你要求太多细节,因为这是敏捷的,所以后期冲刺期间(2周冲刺)的要求会变得更清晰,你不应该担心当时的细节,而是只是让故事在"娃娃头发"中给予重量并且不再困难.做个大人物.不要担心细节.

并不是的.用户故事捕捉了本质,但这并不意味着没有细节.细节在对话过程中传播,对于很好地理解必须做的事情肯定是强制性的(甚至没有提到如果你不知道该做什么和预期什么似乎很难估计任何东西).

传达有关故事的详细信息实际上是产品负责人(PO)工作的一部分.这应该发生在Sprint计划会议的第一部分,其中PO在计划扑克之前和/或在任何需要澄清的任何时候向团队解释每个故事.换句话说,请随时向PO索取详细信息(并向PO询问验收标准).如果存在太多不确定性,请在故事前面做一个大的估计并解释为什么你不能做出"更好"的估计.

对我而言,你的PO /客户/利益相关者似乎并没有非常积极地参与,这是一个非常大的障碍.你的ScrumMaster需要处理这个,没有神奇的解决方案.

Answer 2

你应该根据需要提出尽可能多的细节,以便估计故事.

您可以在故事卡的背面添加一些验收测试标准(这些不必详细说明).

作为客户,我想用信用卡付款......

使用Visa,MasterCard进行测试

顺便说一句,你的故事似乎有点奇怪.它们应该是以客户/特征为中心的.

Answer 3

公司经常采用混合流程策略。话虽这么说，这看起来就像 rad（快速应用程序开发）+ scrum。如果这只是第一个冲刺，那么这是足够的细节来开始。此时，对于第一个冲刺，我建议团队继续前进，确保工作流程可以从头到尾执行，无论它生成的结果如何。这通常意味着进行一些 Pokemon 异常处理（捕获异常而不是特定异常），记录错误并将信息带入下一个冲刺。