我们使用 Scrum。当我们发现用户故事的粒度不足以捕捉完成 sprint 所需的工作时，我们会在 sprint 期间遇到问题。
特别是，我们发现提供给我们的 UI 线框包含的复杂性比原始故事所暗示的要复杂得多（例如，出于可用性原因复制了功能）。这导致燃尽图看起来像是在冲刺的最后一天完成的。
我们在每个 2 周 sprint 开始的星期一花时间回顾项目团队创建的故事，在此期间，我们通常会稍微改进故事并将它们分解为任务，估计每个时间以创建燃尽图图表。在这一天里，我们感觉没有时间有意义地提高故事的质量。
如何最好地打破我们冲刺的故事不完整/不足的循环？
这是项目团队一开始就没有充分确定故事的失败，还是我们（即开发团队）应该承担一些责任？
所以你说的是：
开发团队是否有可能真正与客户/用户交谈？用户故事有时被视为启动对话的一种方式，而不是需求文档/规范。
编辑：一些链接：
编辑：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 的 5%）来梳理产品待办列表，以便准备最重要的故事，并在下一个 sprint之前必要时通过节食来减少它们的大小。而这实际上会让 sprint 计划会议更加顺利。
这是项目团队一开始就没有充分确定故事的失败，还是我们（即开发团队）应该承担一些责任？
恕我直言，责任并不那么重要（可能出于政治原因，但无论如何它们不会产生太多价值），开发团队和项目团队都在共同努力并一起“失败”。这里重要的是检查并适应以消除障碍。因此，让这个问题可见（这是一个障碍）是开发团队的责任。解决这个障碍是 ScrumMaster 的责任。失败是不努力。待办事项梳理会议是一种方法。最后，我相信项目团队会改进并更好地了解开发团队的期望。你们都会产生更好的结果。
这里已经有很多关于你的问题的 scrum 方面的好主意。根据您的评论：
特别是，我们发现提供给我们的 UI 线框包含的复杂性比原始故事所暗示的要复杂得多（例如，出于可用性原因复制了功能）。
我也担心您可能还需要处理您的开发过程。从 UI 中的多个位置访问功能应该是一个简单的添加，几乎不需要任何时间。如果您发现这是一个常见问题，那么您的功能与特定 UI 元素的耦合过于紧密。您的团队可能需要提高他们的设计技能（例如：模式使用）。
这很有趣。看起来您正在 sprint 中进行 sprint 计划？Sprint Backlog 是在 Sprint 计划之前提交的吗？如果是这样，团队如何在不讨论故事细节的情况下致力于 sprint backlog？
另一种方法可能是让产品负责人意识到某些故事由于缺乏清晰度而无法添加到 sprint backlog 中。尤其是验收标准没有被完全理解。这可能会引发与产品负责人的必要对话。理想情况下，它不应该出现这种情况。它应该在回顾中讨论和解决。