Sprint 快要結束了，這張單還差ＯＯ功能，那我先把這張單移動到 done 嘍

下次再開一張單來把後面的內容補上

相信大家一定都有遇過類似的情境

(為了保護當事 Sprint 我已進行了匿名處理)

在運行的過程當中當然不可能每次 Sprint 都是百分之百完成
也當然不一定是每次 Sprint 都有相對好看的 burndown 斜率(忘記在哪一年，burndown 已經移出 scrum 指南)

並且在通往自組織的道路上，有時候勢必得讓球員來兼當裁判
尤其在某些組織內 Scrum Master 與 PO 還會是同一人，這時候自律與規範就顯得格外重要

真的也是滿巧的在我正在幫 Sprint 進行匿名處理的時候，接到了一通 teams call

哥有空嗎?
有 httpOnly 的問題要跟你討論一下
哎平常都叫名字，只有這時候才會晉升哥

PO:測試環境不知道發生什麼事，現在沒有辦法測試，但 Developer 說 local 測過沒有問題。
我:因為我們現在使用的是 Azure APIM ，所以瀏覽器會認為是第三方 cookie ...(以下省略)
PO:既然要在 customDomain 調整後才能測試，那我們下次 Sprint 再進行嘍？
我:沒意見，另外一個 team 有實踐過類似功能，到時候可以問問他們。
PO:那那張 QA 單，我移動到 done 嘍？
先不要...

沒想到可以這麼剛好有熱騰騰的案例讓我遇到，拿來分享。

其實在沒有達到 acceptance criteria 時，能否移動到 done 這件事
很講究當下的情況，我這邊簡單敘述一下我的判斷標準。

1.研究性質的單，花了時間研究後發現不可行，所以無法達到驗收標準。(停損點的概念)
2.與他處合作開發的單，已按照規格書開發，但尚未整合測試。(對方無法及時配合)
3.需求突然發生大幅異動，需要挪到下次 Sprint 開發(驗收標準都跟著變了)

以這次的案例來看我會覺得，既然 QA 單的內容要等到下次調整完才能進行測試
這次應該是不需要特別先移動到 done 下次再開一張新的。

burndown 不是 down 到底才好，
是能夠反應現況才好～

參考資料：
無