A.限制sprint规模。
B.参照经验教训。
C.查询风险登记册。
D.查看信息发射源记录。

A.创建四个象限，显示风险与价值的关系，首先执行高风险、高价值的任务。
B.创建四个象限，显示风险与价值的关系，首先执行高风险、低价值的任务。
C.使用信息发射源，并让开发团队专注于具有最高风险的开发事项。
D.使用鱼骨图查看进度计划、成本和功能性风险之间的关系。

A.团队成员感到压力而夸大项目进展，以便让业务负责人满意。
B.该特性的开发工作已完成，但该特性未发布。
C.该特性的开发工作未获得项目干系人的批准。
D.业务负责人未能在用户故事中定义该特性的验收标准。

A.安排一次产品负责人与高管的会议。
B.邀请该高管参加发布计划会议。
C.邀请该高管参加sprint演示。
D.邀请该高管参加改善活动。

A.与团队开会识别潜在原因并实施调整，以获得稳定的迭代速度。
B.使用之前迭代的最高速度，并将其作为基准。
C.召开团队会议来鼓励合作，实现可持续的迭代速度。
D.引导团队成员之前结对编程，实现理想的迭代速度。

A.要求客户不要那么频繁地更改系统，并在集成中重新测试失败的版本。
B.建议团队在每次发布版本前进行额外的测试。
C.将问题分配给集成主题专家（SME）。
D.在项目团队和客户之间实施反馈回路。

A.对缺席会议执行处罚。
B.通知团队成员他们可以为会议使用网络摄像头或视频会议。
C.允许团队成员呼叫会议线路。
D.强调这一敏捷原则的重要性，并要求每个人亲自出席会议。

A.确保该开发人员理解该功能必须由产品负责人确定优先级。
B.通知客户他们的请求未获得敏捷原则的支持。
C.支持该开发人员的决定，主动解决客户的需求。
D.在产品待办事项中添加该特性，而不进行进一步讨论。

A.鼓励团队在不影响质量的情况下提高速度。
B.要求产品负责人延迟发布计划，直到速度和质量匹配为止。
C.接受高品质和低速度之间的权衡。
D.更改sprint周期以适应延迟交付。

A.计划扑克。
B.记点投票表决。
C.亲和图。
D.斗伦体系