Agile Tour in Sierre SCRUM: User Stories and Their Estimations The truth about user stories! jean.hennebert@hevs.ch 1
Menu Context and objectives of this talk The theory about User Stories Story points or ideal days of work Working with User Stories Your practical feedback (and mine) What is important in all this? 2
Context and objectives of the talk My profile Here you are: SCRUM The fil rouge 3
My agile profile Started applying agility in 2000 About 10 agile projects XP and SCRUM SCRUM master certified in 2009 4
Here you are We talk about being agile and SCRUM...... and user stories 5
Objectives of this talk From the theory of SCRUM about user stories To (your) practical feedback Final points: what we believe is important in all this 6
The Theory about User Stories Multiple levels of planning 2 levels of precision 7
Multiple levels of planning Planning onion - Product / project portfolio - Release planning - Iteration planning - Daily planning 8
2 levels of precision in estimating Product backlog items = user stories with story points or ideal days of work Sprint backlog items = tasks with ideal hours of work 9
Product backlog to Iteration Backlog Product Backlog A prioritized set of user stories planned to enter in the next release of the software The product owner has the responsibility over the product backlog - Determine the best user stories to maximize value - Prioritize their realization from iteration to iteration 10
Product Backlog to Iteration Backlog Iteration Backlog A set of tasks related to selected user stories planned to enter in the next iteration The team has the responsibility over the iteration backlog - Define the tasks to meet the definition of done - Determine the best sequencing to maximize efficiency 11
Iteration 1 Iteration 2 Product Backlog As a book buyer, I want to search for a book by author As a book buyer, I want to add a book in my shopping cart As a shop admin, I want to add a new book As a shop admin, I want to view the current orders As a shop admin, I want to... 3 3 8 5 3 Iteration planning P2 Iteration Backlog Adapt the model 3 Design the UI 8 Code the UI 5 Write tests 3 Write controller 3 Ideal hours Story points / Ideal days Poker planning 12
What s in a user story? User Story - Brief description of functionality as viewed by a user or customer of the system - As a <type of user>, I want <capability> so that <business value> We talk about user functionalities rather than product functionalities - The value is on the side of the user Gun silver bullet principle - A user functionality go through all the layers: from model to view, including docs We really tell a story 13
14
User Story = Gun Bullet = PSPI Documentation... I18N Vue Controller Model Analysis / Specs Institute... PSPI DONE 15
16
Story cards acceptance criteria 17
Size estimation of user stories In SCRUM, the developer team is estimating the sizes of the user stories - It is better to let the ones doing the work estimate its size - The team is learning from iteration to iteration how to estimate Planning Poker games is usually used Poker planning 18
=BIG =Don t know =Time for coffee 19
Story points or Ideal Days of Work? 20
Story points The bigness of a user story It is a fonction of - Complexity - how hard? - Largeness - how much? Points are unit-less Relative comparisons are important - not absolute values 21
Ideal days of work 100% work on project no-interrupts full availability of ressources 22
Story points vs Ideal days Pros Cons Story Points faster to estimate - when used to favor cross-functional behaviors measure the size - do not decay; no need to re-estimate estimates are not deadlines Ideal Days more natural for teams to estimate easier to explain outside of the team less natural for teams to start with difficult to explain outside the team tasks need to be estimated first dependence to individuals measure the length - need to re-estimate when team is faster or when done is re-defined estimates often become deadline 23
User stories to velocity 24
Working with User Stories Estimating Splitting Playing poker 25
How to estimate? By analogy - This story is like that story, so its estimate is what that story s estimate was. - Need of at least one reference story - The one point story - Triangulation - Compare the story being estimated to multiple other stories - Use Estimation Walls 26
Relative values are important - Estimation wall S5 S11 S8 S1 S4 S12 S7 S22 S7 S17 S15 Institute 27
Splitting stories Why: it helps the team estimate something bigger - large estimates are inaccurate - you know how long the smaller stories take - it helps the team and product owner converge into what should be in this big story When: as soon as a story is too big - define a threshold for the team How: - Not too far : tradeoff accuracy vs cost - Keep user stories when splitting! 28
Units Can you make the difference between 18 and 19? Only large relative differences make sense - Typically doubling - Fibonacci suite S P L I T Threshold 29
Story 151: if the user has lost his password, he can ask for a new one by entering his login and email address Size: 3 30
Story 152: The user must be able to search for a book. Size: 40 Too big! split 31
Story 152: The user must be able to search for a book, specifying the ISBN number. Size: 5 Story 153: The user must be able to search for a book, specifying parts or all of the title of the book. Size: 8 32
Planning poker 1. Product owner selects the highest priority story and explains it. 2. Team briefly discuss the story to reach a common understanding. 3. Each team member selects a card. 4. Cards are turned over simultaneously 5. If estimates diverge, ask the outliers to explain (go to 2) 6. If estimates converge, average them Poker planning 33
Why planning poker works? Relative estimating is more tractable Estimates are done by the team Everyone s opinion is heard Iterative approach to reach a common understanding of what s in the story It s quick and fun 34
Practical feedback about all this 35
Let s share our feedback about... Activity Using two levels of planning: user stories that are split into tasks Using story points or ideal days One story = one PSPI - potentially shippable product increment Respect of iterations - time-boxing - no extra stories flying in 36
My opinion - what is important in all this Way of estimating: story points or ideal days - not so important - What is important is that: - estimates are done by the team - estimates are reliable to some extent so that the PO can plan the release - estimates are not becoming deadlines Using two levels of planning: user stories and tasks - This is important because - stories are better to communicate and prioritize - stories emphasize PSPI 37
My opinion - what is important in all this One story = one PSPI - potentially shippable product increment - This is maybe the most important agile practice - From PSPI, most other agile practices derive - Multi-functional, self-organizing team - done - bullet principle - User-client oriented - Software engineering good practices - continuous integration - test-driven development - test automation 38
My opinion - what is important in all this Agile practices are less important than agile values AGILE is about values and principles not practices but many practices support these 39
do agile be agile 40
41 http://agilemanifesto.org/
Some Conclusions 42
Conclusions Theory about user stories - Double level of planning: user stories are declined into tasks - 1 user story = brief description of functionality as viewed by a user or customer of the system - 1 user story = 1 PSPI = 1 bullet going through all software layers - User stories can be estimated with story points (preferred) or ideal days of work In practice - Things may differ from the theory provided that agile values are respected - The principle of PSPI is probably the most difficult one 43
References Certified Scrum Master training from Valtech by Craig Larmann Agile Management with SCRUM, Ken Schwaber, Microsoft Press Agile Estimating and Planning, Mike Cohn, Prentice Hall 2009 Some figures borrowed from - ppt Agile Estimating and Planning, Mike Cohn, SD West 2007 - http://www.mountaingoatsoftware.com - ppt User Stories for the Product Backlog, Ralf Wirdemann, 2009 44
jean.hennebert@hevs.ch 45