Should we stop using story points and velocity? 資工碩一 陳懿婷 Prasanna Vaste Agile India 2014

Outline Introduction:Why Estimate? Motivation Methodology Advantage Conclusion

Introduction: Story point and velocity Story point: What: 分析完成一個 story 所需花費的 effort 。 When: 在 estimate session 中評估。 How: 常見的 Planning Poker 。 Velocity: 每個 sprint 結束後，團隊真正完成的 story point 數量。

Introduction: Why Estimate? 1.Track velocity 2.Decide scope for the Iteration —Story point & velocity 3.Help Prioritize stories 4.Help Release planning

Motivation Estimation takes lot of time and effort. PM tend to relate these estimates to number of days it will take to complete the story. In some teams estimate is equal to deadline. 以上情況導致 -In lack of confidence on development team when stories take more time to complete. So…They use of simple Metric for Project Process Measurement -Use Story Count

Methodology 常見的 Scrum 作法 假設 1 sprint 完成 20 point 約需要 10 個 Spring 來完成 Velocity= 每個 sprint 過後完成的 story point 數量為多少 New Project Story point= Product Backlog

Methodology 作者的作法 New Project sprint 1 (1 week ) Story Count 完成的 Story Count 數量 計算 Number of stories on backlog Number of story completed in a sprint 要花多少個 Sprint 來完成 MVP scope Velocity

兩者差異 Story 切割的方式 -Story Point vs Same size Project Progress Measurement- Story Point vs Story Count Velocity 定義方式 -Story Point vs Story Count

Advantage How Story count helped Product owner and Team were happy with this change as: Less Math, more effective planning Better way to track change in scope More focus on completing stories which give higher business value instead of quick gain in story points.

作者建議 You can evolve your estimation process from “Story Points(Ideal Days)→Relative sizing→Counting cards→Cycle time”

Conclusion Stop wasting time trying to estimate a nerver ending Backlog. There’s no evidence that that will help you predict the future any better than just counting the number of stories “Done”!

備註 :Product Backlog

備註 : MVP(minimum viable product) 用最快最簡單的方式建立一個可用的產品 的原型，來表達產品的效果，進而補充細 節。

Experience He was working for car insurance company to build Mobine web app to allow users to buy car insurance.

Experience They decided to use story count(measure progress by measuring the number of stories completed in an Iteration)

Experience (Method)-Use of simple metric for Project Progress Measurement. 1. 1week to identify the project vision, product backlog,MVP Scope. Product owner 詢問 MVP scope 完成需要花多少時間 與 development 溝通 : 此 story 是否能再 1week Iteration 內 完成 ? 若否, 則再細分 story 。 Team decide to not use story points for estimation Team wanted something simple,easy to track and requires less time for estimation.

Experience-Using Story count Assume all stories are of same size Agile Velocity game to identify team velocity Start Iteration1 and count actual velocity(completed cards count) Number of stories in backlog/ Number of stories completed in a sprint=Number of sprints to complete the MVP scope Relook at velocity after another Iteration and adjust the planned velocity

Claim1 使用 story point 允許我們當有新點子時能改變原來當初的 story >> 當更改幅度很小時，不影響當初所估計的 story point 。 >> 但若幅度很大呢 ? 則需額外開 estimation session 或者再細 分 story 評論 : 如果我們使用簡單的評估方式 (story 已完成的數量 ) 我們 可以快速的評估新的 item 在進度上的影響程度，若用 story points 來計算多少事待完成

作者過去在汽車保險公司工作, 開發 mobile web app > 花一個禮拜來訂定 project vision 及 product backlog MVP Scope ，而 product owner 會粗略的詢問大約要花多少時間來完 成 MVP scope 。我們問 development team 這 個 story 再 1week(iteration) 可以被完成 嗎 ?(pair programing) 若不行，則 story 再被細 分，取代了用 product backlog 來評估。

one can say that by continuously estimating the size of the story you are creating a distribution of the size around the median