如何编写特定于本例中任务的用户故事

Question

我们已经计划了一个用户故事。

作为一名球员，我想查看游戏地图，以了解我的球队目前的排名。

冲刺时间是两周。我们将能够完成仅在两个星期的时间HTML，这个用户故事将需要4-6周才能完成，因为我们的内容设计资源短缺。

我们如何改变这个用户故事，以便HTML完成可以被认为是这个用户故事的完成，并且我们需要在下一个sprint中处理这个用户故事的集成？

是否有可能创建两个不同的用户故事，一个用于HTML，另一个用于集成、测试、错误修复等？

Answer 1

和所有的故事一样，想想你需要什么，它是为了谁，为什么他们需要它。用户不必是最终用户。记住，写故事的最终目的是帮助你和你的团队。你不会因为写符合一本书的定义的故事而得到额外的分数。把故事分解成更小的部分，帮助你的团队集中精力。

例如，一个前端故事：

作为开发人员构建游戏地图，我需要创建HTML标记，以便显示地图。

..。还有一个后端故事

作为构建游戏地图的开发人员，我需要备份API以支持获取游戏数据，以便在地图上显示它。

..。也许是一个设计故事

作为一个开发人员构建游戏地图，我需要最终的样式表来开发，以便用户喜欢使用该地图。

...and等。

Answer 2

我认为您的问题隐藏了一个更大的问题:缺乏内容设计人员(请不要调用人员资源，它使他们非人格化)似乎表明您的团队正在开发筒仓工作。

在最近的一个项目中，我也做过同样的事情。我们有前辈，集成商和后进主义者。

我是个噩梦。虽然前面的人总是很忙，但是集成商不忙，后援们也不知道该先做什么。它最终在一个时间点有40个或更多的未完成的故事，什么都没有完成(除了团队中的问题，我们还不得不无休止地等待另一方完成)。

我们不得不估计故事的完成情况，只是为了给客户一个进展的指示。你的问题让我想起了这一点。是的，我们可以向客户展示模型，但只要他不能使用它们(完成，完整的文档，测试和批准)，他们是没有价值的。

我对你的建议是:当设计内容的人开始写一个故事时，让他们把程序和其他的程序配对。一开始可能会花费一些时间，但从长远来看，这肯定是值得的。有了20%的知识，通常80%的工作可以完成。它可以给当前内容设计人员带来一些压力，并在团队中创建一个更好的流程。