A. 建議聘請外部協助者，因為組織中沒有人能夠消除此障礙。

B. 促進面對面的討論並讓利害關係人同意在未來的專案中轉向敏捷。

C. 組織培訓課程，提高利害關係人對敏捷價值的認識。

D. 允許利害關係人在沒有 Scrum Master 幹預的情況下進行討論。

A. 低風險、高價值

B. 高風險、低價值

C. 高風險、高價值

D. 低風險、低價值

A. 使用投票點數來估計故事點數

B. 使用故事點估計故事的相對大小

C. 透過與類似的過去特徵進行比較來估計故事點

D. 將故事放入桶中來估算故事

A. 確保團隊由跨職能、通用的專家組成

B. 降低此功能的優先級，直到團隊成員掌握了建立此功能的技能

C. 將此功能指派給另一個擁有所需技能成員的敏捷團隊

D. 為特定團隊成員提供所需技能的及時培訓

A. 指定一人與在不同地點工作的所有團隊成員進行溝通。

B. 定期面對面會晤，以增進相互了解。

C. 確定需要外部供應商提供哪些支援來幫助分散的團隊成員。

D. 定義分散的團隊成員可以完成哪些專案工作。

A. 產品目標、策略目標、主要功能和發布計劃

B. 功能、開發階段、技術與基礎設施、依賴關係與風險

C. 產品改善、資源管理、風險管理與截止日期

D. 產品願景、業務目標、主題、時間表和免責聲明

A. 年輕

B. 關鍵績效指標 (KPI)

C. 具體、可衡量、可分配、現實、基於時間 (SMART) 的目標

D. 改善

A. 驗證產品

B. 追蹤進度

C. 估計故事大小

D. 優先考慮故事

A. 與利害關係人的期望和可發布的產品增量保持一致。

B. 展示自我管理和自訂流程以實現持續改進。

C. 提供產品增量的協作和知識分享。

D. 提供對商業價值和顧客回饋的理解。

A. 提醒團隊可能無法實現衝刺目標並制定替代計劃

B. 讓衝刺依計畫進行

C. 獲得團隊支援以對 Sprint 待辦事項進行修改

D. 請團隊決定是否應重新分配任務

A. 透過定期回饋循環來識別專用任務和活動。

B. 將發布版本新增至具有里程碑和活動的路線圖中。

C. 確定設定時間範圍內的需求時間表。

D. 以小規模和持續迭代版本的形式交付。

A. 進行回歸測試，以確保所有先前運作正常的聊天機器人功能在更新後繼續運作。

B. 執行整合測試，以最大程度地減少聊天機器人元件之間的任何錯誤。

C. 進行使用者驗收測試，以確保聊天機器人滿足利害關係人的需求和期望。

D. 執行功能測試以驗證聊天機器人是否執行所需功能。

A. 四個月

B. 八個月

C. 兩個月

D. 六個月

A. 團隊應該使用精實的延遲原則，以便能夠考慮實際情況而不是假設和預測。

B. 應該定期與利害關係人接觸以獲得回饋並降低功能風險。

C. 相互依賴的團隊應該採用協作的方式來確定和利用最佳支援。

D. 應該確定所有者以便及時獲得利害關係人的回饋。