User Story Refinement

更新於 發佈於 閱讀時間約 9 分鐘
圖片來源:www.freepik.com

圖片來源: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)其發想的成果寫成一份詳細的企劃文件(跟團隊過去開發遊戲的經驗有關)。

raw-image

會議有時會搭配可簡單操作的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%的時間,但發想會議常常無法如期結束,有時還要加開,延誤到原本的開發,成員為了追回進度自願加班,就長遠來看這不是好現象。但目前仍有不少團隊成員認為是最好的方式,因為能參與到最一開始的發想,有一種產品就是自己的小孩,而不是幫別人開發產品。

raw-image

就在這兩個需求完成後,團隊開始了另一個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如何進行,這裡簡單分享我們如何改善給大家參考。

留言
avatar-img
留言分享你的想法!
avatar-img
Spirit的沙龍
55會員
107內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
Spirit的沙龍的其他內容
2023/11/01
在上回提到一些應該要避免的措施,以及時時梳理 product backlog 讓團隊有較好的估算,這回則是作為一位 scrum master,我們該如何自省與發現估算的問題,也是以自我反省的方式完結這個系列。
Thumbnail
2023/11/01
在上回提到一些應該要避免的措施,以及時時梳理 product backlog 讓團隊有較好的估算,這回則是作為一位 scrum master,我們該如何自省與發現估算的問題,也是以自我反省的方式完結這個系列。
Thumbnail
2023/10/25
在上回討論 Scrum 對於估算的精神與常見的估算單位,這回就來討論一些應該避免的事項,讓團隊能有更好的估算,下回則是過去的自省與感想。要讓團隊有較高品質的估算,agile coach 或 scrum master 可以觀察一些徵兆,若有發現盡早排除,免得讓團隊成員有壞習慣或是對估算這件事有陰影。
Thumbnail
2023/10/25
在上回討論 Scrum 對於估算的精神與常見的估算單位,這回就來討論一些應該避免的事項,讓團隊能有更好的估算,下回則是過去的自省與感想。要讓團隊有較高品質的估算,agile coach 或 scrum master 可以觀察一些徵兆,若有發現盡早排除,免得讓團隊成員有壞習慣或是對估算這件事有陰影。
Thumbnail
2023/10/18
這同是 2016 年的舊文,根據現在的閱讀習慣重新整理,文章分成三回陸續發布,本回先談談在 Scrum 中,為什麼要估時,然後談談比較常見的單位與用法。下回則是幾個小方法,讓團隊能有更好的估算。最後一回,則是一些過去的自省與感想。
Thumbnail
2023/10/18
這同是 2016 年的舊文,根據現在的閱讀習慣重新整理,文章分成三回陸續發布,本回先談談在 Scrum 中,為什麼要估時,然後談談比較常見的單位與用法。下回則是幾個小方法,讓團隊能有更好的估算。最後一回,則是一些過去的自省與感想。
Thumbnail
看更多
你可能也想看
Thumbnail
在上回提到一些應該要避免的措施,以及時時梳理 product backlog 讓團隊有較好的估算,這回則是作為一位 scrum master,我們該如何自省與發現估算的問題,也是以自我反省的方式完結這個系列。
Thumbnail
在上回提到一些應該要避免的措施,以及時時梳理 product backlog 讓團隊有較好的估算,這回則是作為一位 scrum master,我們該如何自省與發現估算的問題,也是以自我反省的方式完結這個系列。
Thumbnail
在上回討論 Scrum 對於估算的精神與常見的估算單位,這回就來討論一些應該避免的事項,讓團隊能有更好的估算,下回則是過去的自省與感想。要讓團隊有較高品質的估算,agile coach 或 scrum master 可以觀察一些徵兆,若有發現盡早排除,免得讓團隊成員有壞習慣或是對估算這件事有陰影。
Thumbnail
在上回討論 Scrum 對於估算的精神與常見的估算單位,這回就來討論一些應該避免的事項,讓團隊能有更好的估算,下回則是過去的自省與感想。要讓團隊有較高品質的估算,agile coach 或 scrum master 可以觀察一些徵兆,若有發現盡早排除,免得讓團隊成員有壞習慣或是對估算這件事有陰影。
Thumbnail
這同是 2016 年的舊文,根據現在的閱讀習慣重新整理,文章分成三回陸續發布,本回先談談在 Scrum 中,為什麼要估時,然後談談比較常見的單位與用法。下回則是幾個小方法,讓團隊能有更好的估算。最後一回,則是一些過去的自省與感想。
Thumbnail
這同是 2016 年的舊文,根據現在的閱讀習慣重新整理,文章分成三回陸續發布,本回先談談在 Scrum 中,為什麼要估時,然後談談比較常見的單位與用法。下回則是幾個小方法,讓團隊能有更好的估算。最後一回,則是一些過去的自省與感想。
Thumbnail
創業團隊就會很在意story的內容,會有相當多的意見,refinement meeting就是一個很好的場合讓大家把對需求的想法提出來,否則讓成員失去參與感,這對創業團隊是很大的傷害。
Thumbnail
創業團隊就會很在意story的內容,會有相當多的意見,refinement meeting就是一個很好的場合讓大家把對需求的想法提出來,否則讓成員失去參與感,這對創業團隊是很大的傷害。
Thumbnail
當 Story 被確定下來之後 要如何切割 Story  讓他們可以在 Sprint 期間能 Done 過去經驗我們都知道 當 Story 太大的時候要拆小 但問題就來了 小要小到多小 有可能小到 Task 嗎?
Thumbnail
當 Story 被確定下來之後 要如何切割 Story  讓他們可以在 Sprint 期間能 Done 過去經驗我們都知道 當 Story 太大的時候要拆小 但問題就來了 小要小到多小 有可能小到 Task 嗎?
Thumbnail
最近上完了一門 LeSS in Action 的課程 雖然在 Scrum Team 少說也四五年了 這期間也考過了 CSM, PMP 認證 但這次的課程後對 Scrum 又有了新的認識 同時也回顧一下自己在執行了將近五年的 Scrum 開發經驗
Thumbnail
最近上完了一門 LeSS in Action 的課程 雖然在 Scrum Team 少說也四五年了 這期間也考過了 CSM, PMP 認證 但這次的課程後對 Scrum 又有了新的認識 同時也回顧一下自己在執行了將近五年的 Scrum 開發經驗
Thumbnail
Backlog Refinement 能為開發而準備好你所需的 Backlog 。投資此事,能幫助你更快的交付價值、倍增你的生產力,以及建立強大的協作 —即 高績效團隊的支柱。我們發現 Product Owner 在 Backlog Refinement上,需要更進一步的訓練...
Thumbnail
Backlog Refinement 能為開發而準備好你所需的 Backlog 。投資此事,能幫助你更快的交付價值、倍增你的生產力,以及建立強大的協作 —即 高績效團隊的支柱。我們發現 Product Owner 在 Backlog Refinement上,需要更進一步的訓練...
Thumbnail
Sprint Review 是跟利害關係人和客戶建立工作夥伴關係,並取得他們對產品的回饋的特別時段。除了 Scrum 團隊的 Increment,更新的 Release Burndown 和更新的 Team Velocity 等這些...
Thumbnail
Sprint Review 是跟利害關係人和客戶建立工作夥伴關係,並取得他們對產品的回饋的特別時段。除了 Scrum 團隊的 Increment,更新的 Release Burndown 和更新的 Team Velocity 等這些...
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News