本週一召開了第一個spring的spring planning meeting. 對照以前所做spring planning meeting, 覺得我們Team以前很多地方没有落實. 在此將心得整理一下.
這次我自己是Product owner, 找了一位member 作Scrum master
- 說明User story之how to demo的過程, 就是一個跟developer很好的雙向溝通的機會
- 針對story point的估算, 有member反應是要用什麼標準來估算story point? ezScrum團隊說story point是該story 的複雜度, 但它是實作的時間嗎? 倘若對實作story 的技術及domain knowledge不熟悉一定是估不準, 該member反應竟然估不準那就不要表示意見, 聽別人的就好了. ezScrum團隊卻堅持這個story point 是全體成員要一致同意的. Agile estimation 是我一直没有認真study的部份, 所以我決定先follow ezScrum建議的作法.
- 針對一個user story, 我(PO)先assign biz value, developer 再估 story point, 之後我要參考biz value & story point去 assign importance value (優先順序). 身為PO, 有了 story point 我似乎多了一些資訊可以再思考 importance point, 這又是一個溝通的機會.
- User story 要再切割成一個以上的task, 一個task 不能超過13hr. 這個規則讓大家可以認真地將 user story切割成更清楚&有 time-bound 的task.
除了白板之外, 我們也使用了 ezScrum , 做為管理user story 的工具. 有興趣的朋友可以下載來玩看看
