提高用户故事质量

Question

我们使用Scrum。我们在冲刺过程中遇到了问题，当我们发现用户故事没有足够的粒度来捕获完成冲刺所需的工作时。

特别是，我们发现提供给我们的UI线框包含的复杂性比原始故事所暗示的要复杂得多(例如，出于可用性的原因复制了功能)。这导致燃尽图看起来像是在冲刺的最后一天完成了所有的事情。

在每个为期两周的冲刺开始时，我们都会花一个星期一的时间来复习项目团队创建的故事，在此期间，我们通常会对故事进行一些改进，并将它们分解为任务，估计每个任务创建燃尽表的时间。在这一天里，我们感觉没有时间来有意义地提高故事的质量。

对于我们的冲刺来说，如何最好地打破不完整/不充分故事的循环？

这是项目团队在一开始就充分确定故事的失败，还是我们(即开发团队)应该承担一些责任？

Answer 1

所以你的意思是：

1. Customers/users与项目团队交谈
2. 项目团队编写故事并创建wireframes
3. Development团队将故事分解为任务并估计

开发团队是否有可能真正与客户/用户对话？用户故事有时被视为启动对话的一种方式，而不是需求文档/规范。

编辑:一些链接：

• A user story is to a use case as a gazelle is to a gazebo
• Six Features of a Good User Story - INVEST Model
• The Customer is Always Available

编辑: Martin Fowler昨天在ConversationalStories上发表了一篇博文，比我写的要好得多。

Answer 2

你在运行sprint retrospectives吗？在回顾结束时，您应该有高优先级的可操作项目，以改进之前的冲刺中发生的事情。，同样的事情不应该重复出错。。

在冲刺过程中，你的产品负责人可以联系到吗？如果不是，您可能需要添加额外的估计，因为用户故事的细节是不完整的。

@Pascal建议将您的sprint的5%用于产品积压整理，这是一个很好的建议。这将使用户故事在您的sprint开始之前处于更详细的位置。

在每个为期两周的冲刺开始时，我们都会花一个星期一的时间来复习项目团队创建的故事，在此期间，我们通常会对故事进行一些改进，并将它们分解为任务，估计每个任务创建燃尽表的时间。在这一天里，我们感觉没有时间来有意义地提高故事的质量。

这听起来像是你的冲刺计划会议，你能控制你在冲刺期间要完成的用户故事吗？如果你没有足够的细节，你怎么能提交？

这会带你回到有一个很好的回顾和解决所提出的问题。

如何最好地为我们的sprints打破不完整/不充分故事的循环？

回顾、规划、积压整理。

这是项目团队在一开始就充分确定故事的失败，还是我们(即开发团队)应该承担一些责任？

这是整个团队的责任。发现责任不会带来价值，但每个承担责任的人都会给每个人一个成功完成项目的机会。

也许在周一早上的计划会议中，你可以让编写用户故事/线框的人参与进来，一起找出其中缺少的细节，哪些细节会让你的估计更容易、更准确。也许可以为他们应该包括的内容制定一个模板。

Answer 3

我们曾经(并在某些方面继续)遇到过同样的问题。我认为这个问题是缺乏前期分析和开发人员花足够的时间估计用户故事。

你可以从下面这样的故事开始：

As an administrative user I can create a new widget.

好吧，这是什么意思？经过一些分析，这可能意味着：

As an administrative user I can create a new widget in created status with complex data validation errors.

因此，在此之后，将列出字段、大小以及保存到数据库所需的字段。一个基本的UI模型也会很好。

下一个sprint的另一个用户故事可能是：

As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.

然后是复杂验证规则的列表。