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