我正在修改软件工程考试，其中一个问题让我感到疑惑。 它显示了一个燃尽图表，该团队在10天的用户故事中没有取得任何进展。问题是“概述和证明ScrumMaster在此时可能考虑采取的任何行动”。
我考虑过激烈的行动，比如停止冲刺。然后是分配结对编程来帮助用户并考虑更多地分解用户故事。有人有任何其他建议吗？ （这个问题在过去的论文中值得四分。）
答案 0 :(得分：2)
没有足够的信息来提供完整的答案，但根据我的经验，我作为Scrum Master做的第一件事就是查看随时间推移绘制任务小时数的燃尽图（而不是故事点随时间变化）。 / p>
看到几小时被正确烧毁但故事点保持静止是很常见的。通常被称为“迷你瀑布”，因为团队正在离开测试直到Sprint结束，因此在Sprint结束之前不会有任何故事“完成”。
如果我对场景的猜测是正确的，那么，作为Scrum Master，我会花时间在Sprint Retrospective上阐述为什么团队以这种方式工作，以便让他们集中精力让故事“完成”尽可能快地减少WIP。
答案 1 :(得分：2)
我个人讨厌像这样的抽象问题 - 因为你实际上没有足够的信息来提供“好”的答案。冲刺有多长？团队做了什么？缺乏进展的根本原因是什么？如果您是团队的Scrum主人，这些都是您已经知道的事情。你应该从不处于十天后只看燃尽图表的位置，然后找出要做的事情。
例如：
也许团队的任务是在项目环境之外执行“紧急”任务
也许有些故事已经部分完成但由于瓶颈而没有完成（例如故事没有完成，因为没有可用的测试人员，或设计师或最终签署的PO ）
也许故事太大而且花了太长时间 - 或者说故事结果非常复杂，并且暴露了系统的一个区域，这是一个很大的漏洞，很难调整
真正的答案取决于实际的工作环境。如果我被迫给出答案，那就像是：
写一个提醒，弄清楚为什么我会犯规，并且只知道在问题发生十天后有问题需要解决。
写一个提醒，让这个主题在sprint回顾中引起 - 因为一些不好的东西显然正在发生
弄清楚瓶颈/问题是什么，并尝试解决它。如果我们的团队非常擅长自我导向的问题解决，我可能会建议转换到一个工作模式，每个人都聚集在一个故事上，这样我们至少可以完成一些事情。
......但真正的答案是“它取决于”; - ）
答案 2 :(得分：1)
根本原因分析为什么会发生这种情况？这是技能差距吗？关于这个主题的知识，作为一个团队，他们知道如何处理这些用户故事，他们是否在sprint计划会话期间将用户故事分解为任务，PO协作是否足够参与整个过程？
需要一个良好的sprint计划，以及随后的产品backlog修饰会话，如果这些已经发生，他们可以避免这些问题。
如果他们不熟悉技术环境/领域等，那么团队可以采用各种技术，故事或追踪子弹的峰值可能会让他们达到舒适的水平？
最后允许他们作为一个团队失败，并在sprint回顾期间接受。
这是一个scrum master可以有效的地方，一个好的scrum master会记录每日障碍日志，并且主动不允许这种情况发生。
这是我的两分钱。希望对您的考试有所帮助！