我正在复习软件工程考试，其中一个问题让我很困惑。它显示了一个燃尽图，团队在10天内没有在用户故事上取得任何进展。问题是"概述并证明ScrumMaster此时可能考虑采取的任何行动"。
我想过采取激烈的行动，比如停止冲刺。然后是分配结对编程来帮助用户，并考虑进一步分解用户故事。有人有其他建议吗?
我个人讨厌这样抽象的问题——因为你实际上没有足够的信息来给出一个"好的"答案。冲刺多长时间?团队在做什么?缺乏进展的根本原因是什么?如果你是团队的scrum主管，这些都是你已经知道的事情。你应该永远不要处于这样的状态:只看10天后的燃尽图，然后再想办法做什么。
例如:也许团队被指派做项目上下文之外的"紧急"任务
也许有些故事已经部分完成，但由于瓶颈而没有完成(例如，故事没有完成，因为没有可用的测试人员，设计师或PO进行最终签字)
也许故事太大了，花了太长时间——或者故事变得异常复杂，暴露了系统的一个大泥球，很难调整
真正的答案取决于实际的工作环境。如果我必须给出一个答案，我会是这样的:
写一个提醒，弄清楚为什么我搞砸了，只有在问题出现10天后才发现有一个问题需要解决。
写一个提醒，在sprint回顾中提出这个话题——因为很明显有不好的事情发生了
找出瓶颈/问题是什么，并尝试解决它。如果我们的团队非常擅长自主解决问题，我可能会建议切换到一种工作模式，让每个人都集中在一个故事上，这样我们至少可以完成一些事情。
…但真正的答案是"看情况";-)
没有足够的信息来给出一个完整的答案，但根据我的经验，作为Scrum Master，我要做的第一件事是查看燃尽图，该图绘制了任务小时数随时间的变化(而不是故事点随时间的变化)。
很常见的情况是，时间被正确地烧掉了，但故事点却保持不变。通常被称为"迷你瀑布"，因为团队在Sprint结束时才进行测试，所以直到Sprint结束时才"完成"故事。
如果我对这个场景的猜测是正确的，那么作为Scrum Master，我会花时间在Sprint回顾会上解释团队为什么以这种方式工作，以使他们专注于尽可能快地"完成"故事并减少WIP。
可能发生这种情况的根本原因分析?是技能差距吗?关于主题的知识，作为一个团队，他们是否知道如何处理这些用户故事，他们是否在sprint计划会议中将用户故事分解为任务，在整个过程中，PO是否具有足够的协作性?
需要一个良好的sprint计划，以及随后的产品待办事项整理会议，如果这些已经发生，他们可以避免这些问题。
此外，如果团队是技术环境/领域的新手，那么他们可以采用各种技术，例如故事的spike或曳光弹，以使他们达到舒适的水平?
最后允许他们作为一个团队失败，并在sprint回顾中捡起。
这就是scrum管理员可以发挥作用的地方，一个好的scrum管理员会记录每天的障碍日志，并积极主动地防止这种情况发生。
这是我的两分钱。希望对你的考试有帮助!