User Story Refinement

圖片來源：www.freepik.com

最近團隊對refinement meeting有一些討論，過去也曾討論過，我認為這一連串的討論很有意思，所以把從過去到現在refinement meeting如何進行與調整記錄下來。要開始寫這篇時才發現，書到用時方恨少，我手邊竟然沒有半本關於Scrum的書，看完幾本卻始終沒有一本是擺在自己身邊的，只好請Google大神幫我找些資料了。

在水果公司時，團隊算是成功的Scrum團隊，特別是自省會議後對團隊的改善是玩真的，而不只是說說感謝誰或是只聽到好話，檢討起來常常會超出預定的會議時間，有時候還會火力四射，之前的自省會議提到一件事情，就是sprint的planning meeting越來越久，甚至到快用掉半個sprint的時間才把目標確認、task切割和時數估完，原因和scrum的另一個活動有關：refinement meeting。

在繼續討論原因前，我覺得需先說明一下團隊過去refinement meeting的運作情況，我加入團隊時就已有refinement meeting的慣例，由團隊全部成員參與(大約1x人)，時間在每個sprint (一個sprint兩周)第一周的周五。在refinement meeting召開前，PO會將接下來要做的需求(feature)其發想的成果寫成一份詳細的企劃文件(跟團隊過去開發遊戲的經驗有關)。

會議有時會搭配可簡單操作的blueprint雛形展示，然後針對PO將企劃文件所條列的功能切割而成若干的user stories進行討論與估點，當時，這些user stories常遭到抱怨，原因有幾項：(1) 常有非end-to-end的user story、(2) 從模組開發的角度去思考，造成user story間的dependency變高、(3) 從畫面的角度切割，造成user story的內容有重複性、(4) user story的敘述超長卻看不出價值。幾次下來後，在一次的自省會議中，達成了一個共識：user story的切割應該要以使用者能得到的價值為主。

雖然常被抱怨，但當時開發的情況其實還算穩定(burn down chart還算平穩下降)，但有一個現象在當時已經開始浮現：需求從發想、refinement後到開工的時間相當長，因此導致這段時間若干的story後來是被捨棄沒有開發的，我稱之為現象而不是問題主要是，若這些story真的是不需要的，捨棄不開發反而是減少後期開發時間的浪費。

第一次調整後，PO調整了user story的寫法，確實滿足了團隊當初所提的重點：價值導向，但幾次下來，PO開始有點抱怨，而團隊成員也有點抱怨，因為每個story都很大，當時估點story point常常有40這樣的數字出現，當然這樣的story不會被接受，因此refinement meeting常常都是在做切割story，事實上這本來就是refinement meeting要做的事，只是當每次的story都很大，開會時間都超長，團隊中非程式的人員例如美術，常常只是陪程式人員耗著。成員會覺得為什麼不乾脆一開始就讓我們自己寫user story，還比較能節省refinement meeting的時間，此外，PO也覺得每次refinement meeting結束後，為了追蹤確保事情都被完成，他要修改許多文件，包含企劃文件、資訊系統上user story的關聯等等。

因此再次在自省會議中檢討refinement meeting該怎麼進行，會議的結論是：PO不再需要寫一份超完整的企劃文件，只要UX完成一份大概的流程圖就能送進refinement meeting，refinement meeting分成若階段：(1) 第一階段由PO用流程圖解釋需求，全員在當下釐清可行性或是提出改善；(2) 第二階段由程式根據流程圖、end-to-end、價值和施工工法進行story的切割；(3) 對story進行估點，估點時美術團隊會再次加入。這三階段不一定要在一次的refinement meeting中全部完成。

但第一次調整後團隊開發是否有遭遇問題呢？這段期間大概實行了8個sprint，事實上有遇到問題，但和refinement無關，而是別的因素造成，為此還畫了幾次魚骨圖檢討原因(有機會再談)。除此之外，因為由團隊進行再切割，story的規模穩定，且在review時，每個story都有可展示的部分，而時程的估計和實際的開發時間也算吻合，可以說是進入開發速度的穩定期，但後期團隊的成員開始增加，開發速度再次出現變化。

第二次調整只實施了兩個sprint，而用新refinement方式所產出的story，因為整體App上市時程上的考量被封存，並沒有真正地被排入planning meeting中，但平心而論，那兩次的refinement meeting是相當有效率的，而且story的品質是全團隊都認為相當優質的結果，只能說相當可惜。

只實施兩個sprint的主因是，在成員增加到2x人(程式、美術、UX、企劃和PO)後，一次的自省會議上，PO轉達一位(相當重要的)stakeholder的意見：他在一次活動中看到許多新創團隊在很短(相較於我們目前App的已開發時間)的時間就能上架一款App，他覺得團隊的應變速度不夠快。針對這點，長久以來的現象終於被拿出來討論，scrum master將資訊系統中，一個需求從開始發想到開工需要時間大概是兩個月(與團隊討論可行性，幾次往返才能完成發想)，開工後平均的開發時間大概也是一個月到兩個月(視需求大小)，平均來說，一個需求大概要三個月，也可以說團隊的應變時間大概是三個月，雖然不能稱之為waterfall，但在需求釐清確實花了不少時間。

因此，會議中提出了一個建議，團隊分成A、B兩組，每組都有企劃、UX、美術和程式，針對接下來兩個feature，撥出sprint約30%的時間由兩組成員進行發想，發想結果由stakeholder選擇後，馬上進行planning並開發，就時間軸上來看，這兩個feature從發想到完工只花了2-3個sprint，也就是應變時間從三個月縮短到一個月，能縮短到這麼短，真的是因為改變方法嗎？不完全是，就規模來說，這兩個feature相較於過去開發的feature小很多。而且也出現了副作用：sprint n和sprint n + 1這兩個sprint陷入少見的加班期，原因簡單說是過多的context switch，說是撥出30%的時間，但發想會議常常無法如期結束，有時還要加開，延誤到原本的開發，成員為了追回進度自願加班，就長遠來看這不是好現象。但目前仍有不少團隊成員認為是最好的方式，因為能參與到最一開始的發想，有一種產品就是自己的小孩，而不是幫別人開發產品。

就在這兩個需求完成後，團隊開始了另一個client平台Android的開發(原先全力專注在iOS的開發)，也就是文章在一開始提到的情況，Server組和iOS組進入收尾期，Server組開始進行performance tuning，iOS組開始修bug與iOS 8 SDK的升級，由於Android組是移植iOS上所有的功能(直接由我和PO決定story優先順序)，iOS組和Server組要做的事都是技術細節，PO就交由團隊自行選擇，refinement meeting也好幾個sprint沒有舉行，但這出現了一個問題，story的優先順序也由團隊自行選擇，兩組對於微調的優先順序認知不同，有些微調整需要兩組間的配合，於是iOS組想確定Server組是否能配合某些story，Server組也想知道iOS組能配合那些story，雖然最後都能取得共識，但長時間的會議容易造成會議效率的下降，確認這些優先順序花了不少時間。

因此在本文一開始提到的自省會議中再次討論起refinement meeting，決議是refinement meeting還是視情況召開，除有新需求一定會召開外，只要任何成員認為有需要討論story順序或細節就能跟PO要求召開，而且也將時間固定在原本每個sprint第一周的周五，但不相關的成員可以自由參加，例如技術細節的story討論，美術可以不用參加。該自省會議後確實召開了一次refinement meeting，不過是因為新需求而召開，進行方式原則上算是第二次調整和第三次調整的混和體，PO先講解這次UX調整的理念(這部分還是由UX團隊與公司另外一個部門討論後，由stakeholder定案的)，而細節由全成員討論，確認後由開發成員切割story (但竟然忘記估點了XD)，和討論施工的優先順序。

Scrum和過去其他開發法不同，只明確定義了極少的幾個活動，其中refinement meeting大多只提到怎樣的story算是ready to plan，但refinement meeting如何進行較少有討論，畢竟如何進行與團隊特性有關，接案團隊與創業(開發自有產品的)團隊的進行就不一樣，對接案團隊來說，對story本身的喜好，團隊較少會有想法(即便有，通常也不具有決定權)，只要需求明確能夠施工即可；但創業團隊就會很在意story的內容，會有相當多的意見，refinement meeting就是一個很好的場合讓大家把對需求的想法提出來，否則讓成員失去參與感，這對創業團隊是很大的傷害。

目前refinement meeting在幾次的檢討後，算是抓到一個平衡點，但我也不認為我們的團隊會滿足於現況，重要的是持續改善，對於refinement meeting如何進行，這裡簡單分享我們如何改善給大家參考。