我们使用 Scrum。当我们发现用户故事的粒度不足以捕捉完成 sprint 所需的工作时，我们会在 sprint 期间遇到问题。
特别是，我们发现提供给我们的 UI 线框包含的复杂性比原始故事所暗示的要复杂得多（例如，出于可用性原因复制了功能）。这导致燃尽图看起来好像所有事情都在 sprint 的最后一天完成。
我们会在每个 2 周 sprint 开始时的星期一来查看项目团队创建的故事，在此期间，我们通常会稍微改进故事并将它们分解为任务，估算每个故事的小时数创建燃尽图。在这一天里，我们似乎没有时间有意义地提高故事的质量。
如何最好地打破我们的 sprint 故事不完整/不足的循环？
这是项目团队未能在一开始就充分确定故事，还是我们（即开发团队）应该承担一些责任？
【问题讨论】：
标签： scrum user-stories
你是说：
开发团队是否有可能实际与客户/用户交谈？用户故事有时被视为启动对话的一种方式，而不是需求文档/规范。
编辑：一些链接：
编辑：Martin Fowler 昨天在 ConversationalStories 上发表了一篇博文，内容比我做得好得多。
【讨论】：
您是否正在举办 sprint 回顾展？在回顾结束时，您应该有高优先级的可操作项目，以改进上一个 sprint 中发生的事情。 同样的事情不应该反复出错。
您的产品负责人在冲刺期间是否可以访问？如果不是，您可能需要在任何估计中添加额外的内容，因为用户故事的细节不完整。
@Pascal 建议将 5% 的 sprint 用于产品待办事项梳理是一个很好的建议。这应该使用户故事能够在您的 sprint 开始之前出现在更详细的位置。
我们在星期一开始 每个 2 周的 sprint 完成 项目创建的故事 团队，在此期间，我们通常 稍微细化故事并打破 他们分解成任务，估计 每个小时来创建燃尽图 图表。这一天感觉不到 就像我们有时间有意义地 提高故事的质量。
听起来这是您的 sprint 计划会议，您是否可以控制在 sprint 期间您承诺完成哪些用户故事？没有足够的细节怎么提交？
这将带您回到良好的回顾并解决提出的问题。
如何最好地打破循环 不完整/不充分的故事 我们的冲刺？
回顾、计划、待办事项梳理。
这是项目组的失败吗 充分确定故事 一开始，或者我们应该（即 开发团队）采取一些 责任？
这是整个团队的责任。责备并不会带来价值，但是每个人承担责任会给每个人一个成功完成项目的机会。
也许在星期一早上的计划会议期间，您可以让编写用户故事/线框图的人参与进来，共同找出其中缺少哪些细节，哪些细节可以让您的估算更容易、更准确。也许可以制定一个他们应该包括的模板。
【讨论】：
我们曾经（并且在某些方面继续存在）同样的问题。我认为这个问题是缺乏前期分析和缺乏开发人员花费足够的时间来估计用户故事。
你可以从这样的故事开始：
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.
然后列出复杂的验证规则。
【讨论】：
我们在每个 2 周 sprint 开始时的周一来回顾项目团队创建的故事，在此期间我们通常会稍微改进故事。
在 sprint 开始时，故事应该已经准备好了。如果你需要对它们进行一些改进，我认为你（开发团队、ScrumMaster、项目团队）应该在之前的 sprint 中提前一点。
如何最好地打破我们的 sprint 故事不完整/不足的循环？
您可能低估了故事，或者它们太大太模糊。在这两种情况下，这听起来像是一个估计问题，改进的一个好方法是减少故事的大小。要解决此问题，您可以将一些时间（例如，每个 sprint 的 5%）用于Product Backlog Grooming，以便准备最重要的故事并减少它们的大小，如果需要之前 将它们放在on diet > 下一个冲刺。而这实际上会让 sprint 计划会议更加顺利。
这是项目团队未能在一开始就充分确定故事，还是我们（即开发团队）应该承担一些责任？
责任并不那么重要，恕我直言（可能出于政治原因，但无论如何它们不会产生太多价值），开发团队和项目团队都在一起工作并一起“失败”。这里重要的是检查并适应以消除障碍。因此，让这个问题可见是开发团队的责任（它是一个障碍）。解决这个障碍是 ScrumMaster 的责任。失败是不努力。待办事项梳理会议是一种方法。最后，我相信项目团队会改进并更好地了解开发团队的期望。而且你们都会产生更好的结果。
【讨论】：
这里已经有很多关于你的问题的 Scrum 方面的好主意。根据您的评论：
特别是，我们发现提供给我们的 UI 线框包含的复杂性比原始故事所暗示的要复杂得多（例如，出于可用性原因复制了功能）。
我还担心您可能还需要处理您的开发过程。从 UI 中的多个位置访问功能应该是一个简单的添加，几乎不需要任何时间。如果您发现这是一个常见问题，那么您的功能与特定 UI 元素的耦合过于紧密。您的团队可能需要提高他们的设计技能（例如：模式使用）。
【讨论】：
这很有趣。看起来您正在 sprint 中进行 sprint 计划？ Sprint Backlog 是在 Sprint 计划之前提交的吗？如果是这样，团队如何在不讨论故事细节的情况下致力于 sprint backlog？
另一种方法是让产品负责人意识到，由于缺乏明确性，某些故事无法添加到 sprint backlog 中。尤其是验收标准没有被完全理解。这可能会引发与产品负责人的必要对话。理想情况下，它不应该出现这种情况。应该在回顾中讨论和解决。
【讨论】：