Practical Story Sizing Brett Maytom Senior Consultant, Readify Vic .NET – 13 Aug 2011 Talk Backlog What is size Relative Size Sizing Scales Velocity Story Size versus Task Sizing Running Sizing Meetings Questions What is size? Unit of measure for work Why Relative Sizing Your Time IS NOT My Time Size does not … indicate time Indicate skill include risk change over time Increase\decrease with proficiency Relative It’s relative Sizing Scales Fibonacci 1 2 3 5 8 13 21 34 Modified Fibonacci 1 2 3 5 8 13 20 50 100 Binary 1 2 4 8 16 32 64 128 T-Shirt S M L XL Other Symbols 0 (Zero) “Too small and not worth sizing” ? “I have no idea what you are talking about” ∞ (Infinity) “This is way too big” Velocity Rate of work of team “Team can complete X story points per sprint” Not individual Full team including BA, QA, Dev., Test, Architect, Scrum Master Improves with time Story Sizing Uses a relative sizing scale Not done at iteration planning Used for Release Planning 𝐵𝑎𝑐𝑘𝑙𝑜𝑔 𝑆𝑖𝑧𝑒 # 𝑆𝑝𝑟𝑖𝑛𝑡𝑠 = 𝑉𝑎𝑙𝑜𝑐𝑖𝑡𝑦 Stories and Tasks Task Sizing Tasks defined in sprint planning Sized in hours Updated daily with remaining hours Used for sprint burndown Cross-check against Story Size using current velocity Sizing in multi-team Consistent story size critical Large scope differences Clear benchmarks Central team How to play Planning Poker Product owner presents a story Team clarify by asking questions “1 … 2 … 3 … show” Smallest and largest values explain Repeat until consensus reached Spikes Totally new technology Never done before Have no idea how to size work Time-boxed to a few days Acid Test A story sized in the first sprint should have the same size in later sprints Practical Tips Use relative sizes for stories Do not factor in effort, risk and time Build a list of benchmark stories Continually inspect that “time” is not introduced story Differentiate between Task and Story sizes Your Time IS NOT My Time Thank you Brett Maytom brett.maytom@readify.net @brettmaytom http://brett.maytom.net