Working effectively with user stories

1,882 views

Published on

Slide deck from my talk/workshop at Agile 2012 in Dallas Texas, Tuesday August 14 2012.

The title is "Working Effectively with User Stories"

The workshop and talk covered four main topics:
1. Silent Grouping: A technique for sizing large sets of user stories
2. Definition of Ready
3. Backlog Grooming
4. Tracking Progress as part of Daily Standups

Published in: Technology

Working effectively with user stories

  1. 1. WORKINGEFFECTIVELY WITHUSER STORIESKen Power
  2. 2. Agenda•  Sizing (large) sets of User Stories quickly•  Definition of Ready•  Backlog Grooming•  Daily tracking of progress of User Stories
  3. 3. About me•  My day job §  Co-Founder, Agile Office at Cisco §  Internal Agile & Lean Coach/Consultant•  Extra-curricular activities §  Fellow of the Lean Systems Society (http://LeanSystemsSociety.org/) §  Award-winning publications in Agile and Lean product development §  Frequent speaker at major international Agile and Lean conferences §  Involved in organizing international Agile and Lean conferences §  Industry/academic collaborative research on Agile and Lean software development §  Blog: http://SystemAgility.com/
  4. 4. What are we estimating? Size: How big is the work? Duration: How long will it take? Date: When will the work be done? Staffing: Who will do the work?
  5. 5. RELATIVE SIZING
  6. 6. How big is the pile of work?
  7. 7. SIZING USER STORIES
  8. 8. 1 2 3 5 8 13 21 34
  9. 9. The Basic Stepshttp://systemagility.com/using-silent-grouping-to-size-user-stories/Power, Ken. "Using Silent Grouping to Size User Stories." In AgileProcesses in Software Engineering and Extreme Programming 12thInternational Conference (XP 2011). Madrid, Spain: Springer Lecture Notes inBusiness Information Processing (LNBIP), 2011.
  10. 10. 1 2 3 5 8 13 21 34 Do something cool Do something cool Do something cool Do something cool Do something cool Do something cool As a As a As a UserDo something cool User User As a As a Do something cool As a I want to I want to I want to User User User do something cool with the do something cool with the I want to I want to do something cool with the As a I want to product product product do something cool with the do something cool with the User As a do something cool with the So that I can product product So that I can So that I can I want to User product benefit in some way benefit in some way So that I can So that I can I want to benefit in some way do something cool with the benefit in some way benefit in some way So that I can product do something cool with the benefit in some way product So that I can benefit in some way So that I can benefit in some way Do something cool Do something cool Do something cool Do something cool Do something cool As a As a As a UserDo something cool User User As a Do something cool As a I want to I want to I want to User User do something cool with the do something cool with the I want to do something cool with the As a I want to product product product do something cool with the User As a do something cool with the So that I can product So that I can So that I can I want to User product benefit in some way benefit in some way So that I can I want to benefit in some way do something cool with the benefit in some way So that I can product do something cool with the benefit in some way product So that I can benefit in some way So that I can benefit in some way Do something cool Do something cool Do something cool Do something cool As a Do something cool User Do something cool I want to As a As a As a User User As a do something cool with the I want to User product I want to I want to User As a User do something cool with the do something cool with the I want to So that I can do something cool with the benefit in some way I want to product product product do something cool with the do something cool with the So that I can product So that I can So that I can product benefit in some way benefit in some way benefit in some way So that I can benefit in some way So that I can benefit in some way Do something cool Do something cool Do something cool Do something cool As a User Do something cool I want to As a As a As a User User do something cool with the I want to User product As a I want to I want to User do something cool with the do something cool with the do something cool with the So that I can product benefit in some way I want to product product do something cool with the So that I can So that I can So that I can product benefit in some way benefit in some way benefit in some way So that I can benefit in some way Do something cool Do something cool Do something cool As a As a As a User User User I want to I want to I want to do something cool with the do something cool with the do something cool with the product product product So that I can So that I can So that I can benefit in some way benefit in some way benefit in some way Do something cool Do something cool Do something cool As a As a As a User User User I want to I want to I want to do something cool with the do something cool with the do something cool with the product product product So that I can So that I can So that I can benefit in some way benefit in some way benefit in some way Do something cool Do something cool As a As a User User I want to I want to do something cool with the do something cool with the product product So that I can So that I can benefit in some way benefit in some way Do something cool As a User I want to do something cool with the product So that I can benefit in some way
  11. 11. The 6 myths of Product DevelopmentHigh utilization of resources[and people] will improveperformance Processing work in large batches improves the economics of theOur plan is great; we processjust need to stick to it The sooner the project is started, the sooner it will be finishedThe more features we putinto a product, the morecustomers will like it We will be more successful if we get it right the first time D.#G.#Reinertsen,#“The$principles$of$product$development$flow$:$second$genera8on$lean$ product$development”.#Redondo#Beach,#Calif.:#Celeritas,#2009.# # # S.#Thomke#and#D.#Reinertsen,#"Six$Myths$of$Product$Development,"#Harvard#Business# Review,#vol.#90,#pp.#84G94,#May#2012#
  12. 12. Waste in Product Development“Eliminating waste is the 1.  Extra Featuresmost fundamental lean 2.  Delaysprinciple, the one from 3.  Handoffswhich all the other 4.  Extra Processesprinciples follow. Thus,the first step to 5.  Partially Done Workimplementing lean 6.  Task Switchingdevelopment is learning 7.  Defectsto see waste.” 8.  Unused Employee - Poppendieck and Poppendieck 2003 Creativity
  13. 13. Premature Precision“Both business and programmers are tempted to fall intothe trap of premature precision. Business people want toknow exactly what they are going to get before theyauthorize a project. Developers want to know exactly whatthey are supposed to deliver before they estimate theproject. Both sides want a precision thatsimple cannot be achieved, and are oftenwilling to waste a fortune trying to attain it.” -  Robert C. Martin (Uncle Bob) “The Clean Coder: A Code of Conduct for Professional Programmers”
  14. 14. STARTING RIGHT
  15. 15. Reminder: Definition of Done
  16. 16. SycnhronizationPointDefinitions of Ready & Doneact as focusing anchors forteams, management, andeveryone involved in creatingand delivering the product
  17. 17. Do something cool As a User I want to do something cool with the product So that I can benefit in some wayConcept Happy User
  18. 18. Level of Focus on the User Story Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  19. 19. Level of Focus on the User Story Done Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  20. 20. Level of Focus on the User Story Done Ready Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  21. 21. Level of Focus on the User Story Done Ready Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  22. 22. Level of Focus on the User Story Done Ready Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  23. 23. Level of Focus on the User Story Done Ready Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  24. 24. Level of Focus on the User Story Done Ready Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  25. 25. Level of Focus on the User Story Done Ready Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  26. 26. Level of Focus on the User Story Done Ready Product Owners Team Concept Time TStart Done Accept TEnd Ship It
  27. 27. Why have a Definition of Ready?•  So everyone knows when a User Story is really ready to be pulled in by the team §  It does not need to be “100% defined” with all acceptance criteria, etc. §  It does need to be “ready enough” so that the team is confident they can successfully deliver
  28. 28. Exercise/Discussion:So, what do we need to do to make sure a User Storyis really Ready to be pulled in by the team?
  29. 29. Definition of Ready for a User Story•  User Story defined•  User Story Acceptance Criteria defined•  User Story dependencies identified•  User Story sized by Delivery Team•  Scrum Team accepts Ux artefacts•  Performance criteria identified, where appropriate•  Person who will accept the User Story is identified•  Delivery Team has reviewed and accepted the User Story•  Team has a good idea what it will mean to Demo the User Story
  30. 30. Definition of Ready for an Iteration•  The Iteration Backlog is prioritized•  The Iteration Backlog contains all defects, User Stories and other work that the team is committing to §  No hidden work §  Examples of ‘other work’ might include lab setup, build environment maintenance, creating a test app, working on your manager’s pet project, supporting another product•  All team members have noted their capacity for the Iteration•  All User Stories meet Definition of Ready
  31. 31. “Never pull anything into a Sprint that is not Ready. Never let anything out of a Sprint that is not Done.” - ? Sorry: can’t recall the Source!
  32. 32. Consequences of not being Ready •  The Team is estimating and forecasting that they can finish vague and incomplete stories. •  They waste time and energy trying to get clarity from the Product Owner on exactly what the story means. •  People get frustrated and annoyed and run around in circles rather than getting down to work. •  That one vague story actually turns out to be five real stories once the work is actually begun. •  They work on the wrong thing, or the right thing in the wrong way, forcing the work to be re-done.Jeff Sutherland (2012). "The Dangers of Not Being Done, Or Ready For ThatMatter”. Available from http://scrum.jeffsutherland.com/
  33. 33. BACKLOG GROOMING
  34. 34. Continuously Groom the Backlog and Re-evaluate where you are Scope Current Active Next Iteration Iteration Distant Iteration (Iteration N N+2 to N+3 Future (Iteration N) +1) (Iteration N+4 and Beyond) % 75% 50% 25% N/ACertainty Backlog Epics, User Epics, Epics, Ideas, Item Stories, Use Themes, Themes, Features,granularity Cases Features, Use Features, Themes, Wish Cases Ideas lists
  35. 35. TRACKING PROGRESS
  36. 36. Typical Daily Standup questions•  What did you do since we last met?•  What will you do before we meet again?•  What obstacles are in your way?
  37. 37. But …
  38. 38. Can start to break away from Dreyfus model for individual, team and fixed rules, but have difficulty troubleshooting; Can start using advice in correct organization progression Little or no experience; context; Can start formulating some principles but no “big picture”;Not aware that the a Need a recipe nce No holistic understanding, and 5 – 10+ xproblem exists, orcan’t conceive that Perform don’t want it yetthere is a different 3-5 xway of doing things 1-2 x Expert Breakeven Proficient Competent Primary sources of knowledge and Advanced information in any field Beginner Continually look for better Novice methods and better ways of doing things Vast body of experience bili ty they can tap into and Need e c / Capa apply in the right context peten the big picture Com Frustrated by oversimplified information Work from intuition, not reason Can reflect on previous poor task performance; Can distinguish between can reflect and revise to perform better next time irrelevant details and Can learn from experience of others; can important details understand and apply maxims (as distinct from recipes)
  39. 39. Pay attention to body language
  40. 40. Planned Ready for In Progress Done Accepted (Ready) TestFocus on the Work Items
  41. 41. 27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defectsAdd some project context
  42. 42. 27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defects Time Off: Mary (Holidays – 3d) Joe (Holidays – 1 wk) John (Training – 2d) Exec Demo Tue 13th Customer Visit Thursday 15thAdd some event context
  43. 43. 27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defects Time Off: Mary (Holidays – 3d) Joe (Holidays – 1 wk) John (Training – 2d) Exec Demo |||| Tue 13th Story Title ||| Story Title || Customer Visit As a .. As a .. Thursday 15th <user who requires this <user who requires this feature> feature> I want .. I want .. <goal> <goal> So that... So that... <business justification> <business justification>Understand how the work is aging
  44. 44. 27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defects Time Off: Mary (Holidays – 3d) Joe (Holidays – 1 wk) John (Training – 2d) Exec Demo Story Title ||| Story Title |||| Tue 13th || Customer Visit As a .. As a .. <user who requires this <user who requires this Thursday 15th feature> feature> I want .. I want .. <goal> <goal> So that... So that... <business justification> <business justification>Personalize the Work Items using Avatars
  45. 45. Identified In Progress Resolved Obstacle Title Scrum Master: Name Date Opened: 8-Jan-2012 Date Closed: 14-Feb-2012 Description: alsdals,d askdkas asdkma Asdasd lasdlkalskd alksdl asd asdaskl Resolution: askdmkasd asd asdj nasd Asdasdj asjdj nasd Becomes aKeep an Obstacle Board record of improvements
  46. 46. Time: Monday Tuesday First thing in the 09:00 morning Uninterrupted Uninterrupted Focus Time Focus Time 12:30 Just before Lunch Lunch Time Lunch Time 1:30 Uninterrupted Just after Lunch Focus Time Uninterrupted Focus Time 5:00 Late in the afternoonJust examples:your times may varyThe best time to have Daily Standups isat natural break points in the day
  47. 47. SummarySize User Stories using Silent Grouping Don’t start working on anything that is not Ready Continuous groom your backlog to get things Ready Understand the life cycle of the work through User Stories
  48. 48. Thank You!

×