團隊在衝刺會議喬好完整的衝刺會議，一切都會按照預計的目標前進，敏捷開發一切都是如此美好嗎?怎麼可能呢!!
現實中，團隊總是會面臨天上飛來的插單，讓敏捷都不敏捷了，我們的團隊也難逃這樣的命運。

在回顧會議結束後，開發團隊會進行切版部屬至測試環境，由QA進行測試驗收，若測試未通過時，則會直接請工程師由測試區改回開發區；除此之外，已經運行在正式站台的系統，也會遇到使用者提出緊急的系統bug，需要讓工程師可以直接在從正式區往前改回測試區、開發區，以確保程式一致。

當開發團隊除了預排的衝刺目標以外，還得接單QA、使用者天外飛來的緊急議題，每個人都只有兩隻手，且在有限的時間內，團隊要如何做取捨呢?

一開始衝刺週期為兩周，完全無法消化上述的開發狀況，團隊在經過連續2個衝刺目標Delay狀況下，曾經使用了以下兩種不同的解決方案來解決臨時插單的問題

方式1：成立維運小組
在現有人力狀況下(2位前端工程師、2位後端工程師)，每個衝刺採用輪流方式任選1位前端工程師、1位後端工程師，擔任議題值日生，若有議題需要處理時，就由議題值日生負責維運處理。

看似完美的計畫，但實行後才發現，這個方式的副作用可不少，首先開發新故事的開發人力立刻減少50%，所提列的衝刺故事數量也大幅降低，但預先留下的議題值日生人力，若遇到議題數量沒有很多時，也無法在即時提供故事需求給開發，反而造成開發人力的浪費。此外，每次插單的議題並非議題值日生可以處理時，仍然會占用到其他工程師支援查問題的時間，這個方式在歷經2個衝刺也就被團隊給汰換掉了。

<待續..>