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如何進行,這裡簡單分享我們如何改善給大家參考。

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
Waterfall 陰魂不散
閱讀時間約 6 分鐘
意志力不是萬能丹
閱讀時間約 6 分鐘
從 1 到 5 scrum teams 的心得文
閱讀時間約 4 分鐘
你可能也想看
淺談八維——Fi/Fe user對於情緒的處理現象嗨,我是小七! 本期是個人接觸八維後, 結合理論、各種參考資料和自己觀察的一些綜合成果。 這是談Fe/Fi的第一期,來講講不同的人格如何處理「自己的」情感。 不懂八維、Fe、Fi是什麼的小伙伴也不用擔心, 我會先用白話文大概提一下基本概念。 (=´∀`)人(´∀`=)
avatar
二十一
2023-05-03
【收息平台Q&A】哪個收息平台的界面最User Friendly、客服最好呢?︱小K投資理財之路哪個收息平台的界面最User Friendly? 哪個收息平台的客服最好? 一個平台的客服好壞,決定這個平台能不能把顧客留著,因此,在進入不同收息平台的時候,小K第一時間會測試的就是它們的客服。 寄語 【收息平台】
Thumbnail
avatar
小K投資理財之路
2022-05-22
user真難伺候唉!這user可真難伺候啊~~~
Thumbnail
avatar
ysf
2022-02-27
Someone is selling 1.5 billion Facebook user data on a hackeThe compromised user data included name, email address, location, gender, phone number and user ID.
avatar
陈彤
2022-01-27
User Friendly 「一九七九年,語言學家雷可夫和哲學家詹生合作,開始調查譬喻的運作方式。他們在著作《我們賴以生存的譬喻》提出一個激進的概念,表示少了譬喻我們幾乎無法思考…此外,譬喻的基礎一定是最基本的心智模型:我們對現實世界的物理認知…自從體現認知(embodied cognition)的概念首次提出,實驗心理學家
Thumbnail
avatar
Benson Wu
2021-07-31
讀後感:產品管理流程中,使用者故事(User Story)常見的三種使用情境每周一篇文章的讀書會心得報告摘要與筆記,本次分享的文章為:產品管理流程中,使用者故事(User Story)常見的三種使用情境。 1. 什麼是使用者故事(User Story)? 2. User Story 的三種使用情境 3. 不同團隊會有不同的作法 4. User Story 常見問題
Thumbnail
avatar
Patrick.Wong
2021-07-28
Laravel 8 JWT Multi-User Authentication如上篇,Laravel JWT預設只能認證一種user,但實務上我們可能有不同的role需要各自做Authentication,例如我們有管理員、客戶、員工,等等。 Note: 小弟一開始是參考了網路上各種教學,但都是Laravel較舊版本的教學,經測試在Laravel 8無法work(也有可能是我
Thumbnail
avatar
Vic Lin
2020-12-07
Why User Experience design is so important? In terms of design, user experience design is just as important as user interface design or visual identity. It doesn’t matter what your site or app
avatar
Marlon Francis
2020-03-19
Why User Experience Design is so important? In terms of design, user experience design is just as important as user interface design or visual identity. It doesn’t matter what your site or app
avatar
Marlon Francis
2020-03-18
【商業分析工具:User Story】看懂故事背後的故事,你會一個發現很不一樣的世界。說故事很簡單,但要說個好故事很困難。看故事很容易,但要看出故事背後的故事,就沒那麼容易。 如果你想用聽的,歡迎來到我的 Podcast Blog →【DK Opinion】 越好用的工具,往往越難被理解;越簡單的東西,用對了,往往威力強大。 什麼是使用者故事?User Story? 在商業分析的
Thumbnail
avatar
DK 耀尊
2019-10-15