Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Certified Scrum Product Owner: class desk, posters and photos

7,759 views

Published on

A post-class brochure from one of my Certified Scrum Product Owner trainings in 2016.

Published in: Technology

Certified Scrum Product Owner: class desk, posters and photos

  1. 1. Agile product management With scrum Alexey Krivitsky, CST www.agiletrainings.eu
  2. 2. Agile Coach developer, scrum master, scrum trainer, free-rider Alexey KRIVITSKY www.agiletrainings.eu 1980 – present Kiev – Hamburg
  3. 3. Part 1 Lean Agile scrum
  4. 4. Customer collaboration over contract negotiation
  5. 5. 1930-1950 Taiichi Ohno Deming Shewhart
  6. 6. Lean classifies 8 Wastes “Tim Woods” Transportation moving parts, people, informa7on Inventory storing parts, documen7ng Motion bending, turning, reaching, li=ing Waiting for parts, info, equipment, tools Over production making more than is immediately required Over processing 7ghter tolerances and more efforts than necessary Defects rework, scrap, incorrect documenta7on Skills under u7lizing capabili7es, inadequate trainings
  7. 7. WHAT ARE THE TOP WASTES IN SOFTWARE DEVELOPMENT?
  8. 8. The CHAOS Report hDp://www.standishgroup.com/Reports2015
  9. 9. scrum is a product development framework scrum connects product people with development teams. Scrum helps learn fast by inspecting and adapting product and process. Scrum exposes your process inefficiencies – it is like a mirror.
  10. 10. Which Terms from the List Are Not Part of Scrum? User Stories Velocity Metric Grooming Meetings Continuous Integration Automated Testing Monthly Releases Visual Task Boards Story Points
  11. 11. Scrum 101 Scrum Roles: 1.  Product Owner “P.O.” 2.  Development Team 3.  ScrumMaster Scrum Artifacts: 1.  Product Backlog (PBL) 2.  Sprint Backlog 3.  POTENTIALLY SHIPPABLE Product Increment “PSPI” Scrum Ceremonies: 1.  Sprint 2.  Sprint Planning 3.  Daily Scrum 4.  Sprint Review 5.  Sprint Retrospective
  12. 12. dual track scrum
  13. 13. Part 2 PRODUCT OWNER
  14. 14. Product Owner Waiter or doctor?
  15. 15. http://www.agileproductdesign.com (Jeff Patton) Shared documents ≠ shared understanding “I’m glad we all agree”
  16. 16. http://www.agileproductdesign.com (Jeff Patton) Help externalize ideas and see differences “Oh…”
  17. 17. http://www.agileproductdesign.com (Jeff Patton) Help to have regular discussions “Ah ha!”
  18. 18. http://www.agileproductdesign.com (Jeff Patton) That will lead ultimately to shared understanding “I’m glad we all agree then”
  19. 19. Defining Product Owner A Product Owner is not a new name for a tradi7onal project manager who delivers a scope and date contract of work. Rather, (s)he has the independent authority to choose and change content, release dates, priori7es, vision, etc. Of course, (s)he collaborates with stakeholders and teams, but a real P.O. has the final decision-making authority.
  20. 20. How Many Product Owners do you need? A company develops a web-shop with services like: a catalog, user profiles, email subscrip7ons, persistent shopping cart, payments and B2B- integra7on for partner shops. How many products do you iden7fy? How many Product Backlogs will you have? How many Product Owners will you need?
  21. 21. Overall Product Backlog for Web-Shop Scrum Teams Single Product Increment one sprint Scrum @SCALE: One product owner per a product one demo one deployment environment one codebase, one repo, one master one set of tests, one con7nuous integra7on
  22. 22. Visit less.works Large-scale scrum
  23. 23. Part 3 LEAN STARTUP
  24. 24. Minimize building Maximize learning.
  25. 25. types of hypothesis 1.  Problem hypothesis We assume there a problem. 2.  User hypothesis We assume these people have this problem. 3.  Solu6on hypothesis We assume our solu7on will solve it. 4.  Growth hypothesis We assume there are enough users.
  26. 26. Pivot examples 1.  Odeo began as a network where people could find and subscribe to podcasts. 2.  This company actually began as an online role-playing game called Game Neverending, where users would travel around a digital map, interact with other users and buy, sell and build items. 3.  It was developed by a company called Confinity in 1999 to allow people to “beam” payments from their PDA. 4.  In 2007 a website called The Point was created which was a “social good” fundraising site that ran on a “7pping point” system, where a cause would only receive funding once the pledged dona7ons reached a certain number.
  27. 27. What will you do when you learn your hypothesis were wrong? Agile makes Changing your mind legal.
  28. 28. Part 4 Knowing your users
  29. 29. Design thinking
  30. 30. Knowing your users 1.  Demographics who are they? 2.  Values, Goals, Behaviors what do they want to achieve? how do they do their work now? 3.  Needs, Frustra6ons, Problems what is their pain?
  31. 31. User Interviews PREPARING 1.  Know what you want to learn 2.  Target the right users 3.  Look for facts, not opinions 4.  Poll enough users to get generalized informa7on
  32. 32. User Interviews RUNNING 1.  Ask open-ended ques7ons 2.  Ask for examples 3.  Ask ‘why’ many 7mes 4.  Be open to learn unexpected things
  33. 33. Listen to what your users want. But offer them what they need.
  34. 34. Part 5 Maximizing impact
  35. 35. Impact Mapping 1.  WHY which business impacts are we to reach? 2.  WHO who are the actors to help us reach the impact? 3.  HOW how the actors will do it? 4.  WHAT what exactly will we do?
  36. 36. Part 6 Defining mvp
  37. 37. how fast can you learn? Do you need to build all product to see if it is valuable and usable? Can you build a part of it to validate your key assumptions? Can you build bare minimum to learn? Can you not build it and still learn?
  38. 38. Build an MVP 1.  Explainer Video 2.  Landing Page 3.  Wizard of Oz 4.  Concierge 5.  Fund Raising 6.  Single Featured hDp://7nyurl.com/mvp-ideas hDp://scalemybusiness.com/the-ul7mate-guide-to-minimum-viable-products/
  39. 39. Part 7 Designing solutions
  40. 40. How and where do you keep your product ideas? Say “yap” if you keep them in the Product Backlog. Say “whoopsi” if you Product Backlog has more than 100 items. Say “yaks” if you need to use some sort of epics/themes/lables in your backlog tool to group the items so that they can be found?
  41. 41. So how and where do great POs keep the product ideas so that the storage doesn’t turn into a junk yard?
  42. 42. So how and where do great POs keep the product ideas so that inventory management costs are kept low?
  43. 43. USER ACTIVITIES (BACKBONE) USER TASKS (WALKING SKELETON) time priorities RELEASES MMP
  44. 44. Ac7vi7es: What the user wants to do? User Tasks: How does (s)he do it? Steps? User Stories: What are the op7ons of performing the task? The simplest? More elaborated? Even more?
  45. 45. Story Mapping A mul6-dimensional Product Backlog that keeps the mul6-dimensional nature of a Product Backlog intact.
  46. 46. Scrum Inception The bare minimum to start scrum 1.  Common understanding of Scrum roles 2.  Team arrangements 3.  Initial Product Visioning 4.  User personas, user/market insights 5.  Story mapping 6.  Initial Release Planning: MVP, next releases 7.  Defining Done 8.  User Story Writing Workshops (minimum: Product Backlog for the 1st sprint) 9.  Backlog refinement 10.  Sprint Planning Product Visioning Release Planning Sprinting Process Agreements
  47. 47. Part 8 Backlog management
  48. 48. USER STORY FORMAT As a <role> I want <action> So that <outcome>
  49. 49. 3Cs with user stories Card Conversation Confirmation
  50. 50. Product Backlog Iceberg Priority2-3 Sprints Release Next Releases Refined User Stories Non-Refined User Stories Epics
  51. 51. Types of PBIs VISIBLE FEATURE VISIBLE DEFECT HIDDEN ARCHITECTURAL FEATURE TECHNICAL DEBT Posi7ve Value Visible Invisible Nega7ve Value
  52. 52. Backlog Management BUGS 1.  Build quality IN – avoid bugs (lean thinking) 2.  Avoid bug inventories. Introduce limits (<50) 3.  Legacy systems - ‘Clean up’ sprints 4.  Zero-bug policy: kill’em before they grow
  53. 53. MIXING WORK IN PRODUCT BACKLOG HIDDEN TECHNICAL DEPT VISIBLE FEATURE HIDDEN ARCHITECT. IMPROVEMENT VISIBLE DEFECT
  54. 54. PRODUCT BACKLOG SHOULD BE DEEP Detailed Appropriately Estimated Emergent Prioritized
  55. 55. Prioritization Techniques
  56. 56. Prioritization Techniques 1.  Rela7ve Ranking 2.  Buy a Feature 3.  Kano Weigh7ng
  57. 57. Stakeholder Classification IMPORTANT keep sa7sfied INFLUENCE INTEREST OTHERS monitor KEY PLAYERS manage closely AFFECTED keep informed
  58. 58. Prioritization requires Scrutiny
  59. 59. Stakeholders “Buying” Features Features Price Tag (complexity*10) Stakeholder A (50 dollars) Stakeholder B (50 dollars) Stakeholder C (70 dollars) Feature A 100 25 25 50 Feature B 20 Feature C 50 25 25 Feature D 100 Feature E 50 Feature F 20 20
  60. 60. Relative Ranking Features A Rela6ve Biz Value (1-Lo, 10-Hi) B Rela6ve Complexity (1-Lo, 10-Hi) C Rela6ve Penalty (1-Lo, 10-Hi) Rank A / B * C Feature A 10 1 1 10 Feature B 1 1 1 1 Feature C 5 2 1 2.5 Feature D 1 8 10 8 Feature E 8 8 5 5
  61. 61. Find Exciters, Linear, and Mandatory Features of an iPhone
  62. 62. How do you feel without Feature-X? How do you feel with Feature-X? GOOD OK BAD GOOD OK BAD Kano Weighting EXCITER LINEAR MANDATORY
  63. 63. Mixing up a Release All from Mandatory 1+ Exciter Key Liners
  64. 64. Product Backlog Refinement Item size Level of details LARGE & UNREFINED SMALL & UNREFINED CLEAR, TESTABLE & FEASIBLE © Roman Pichler 1. ESTIMATE 2. SPLIT 3. REFINE
  65. 65. PRODUCT BACKLOG REFINEMENT IS THE PBI 1/10 to 1/6 OF TEAM’S VELOCITY? SPLIT IT REFINE IT NEXT PBI NO IS THE PBI CLEAR, FEASIBLE AND TESTABLE? NO YES YES
  66. 66. DEFINITION OF READY An agreement within a Scrum team on what a good PBI is - when is it ready for Sprint Planning. •  How to demo is clear •  Discussed with all team members •  Value is clear •  Small enough (es7mated) •  Detailed enough •  Can be started next sprint •  All inputs provided •  No blocking issues •  … •  How to measure user sa7sfac7on •  How to roll out and roll back
  67. 67. How to Split Backlog? You are adding payment capabili7es to a web-shop. Your teams iden7fied that you’ll need a database, valida7on logic, integra7on with several APIs, build a UI. Your teams want to create the following product backlog items: 1.  Create database to store transac7ons 2.  Integrate with APIs 3.  Transac7on valida7on 4.  Develop UI for payment processing What would you say?
  68. 68. ? Overall Product Backlog Scrum Teams Payment DB Payment API Payment Valida7on Payment UI Technical Split one sprint
  69. 69. DATABASE BUSINESS LOGIC API FRONT-END Component Teams
  70. 70. Overall Product Backlog Scrum Teams Payment DB Payment API Payment Valida7on Payment UI Technical Split one sprint
  71. 71. Overall Product Backlog Scrum Teams Payment DB Payment API Payment Valida7on Payment UI Technical Split one sprint one more sprint one more sprint
  72. 72. INSTEAD Split BY BUSINESS VALUE Payment Payment with Visa Payment with MasterCard Payment with PayPal User is informed if card data is not OK User is taken to success page User is taken to retry page User can store his card data Too big for a sprint S7ll too big for a sprint
  73. 73. Overall Product Backlog Development Teams Payment with Visa Payment with MasterCard Confirma7on Email Payment with PayPal SCRUM @SCALE v1 1 PO Common Sprint Single PSPI
  74. 74. Split these stories 1. As a par7cipant I can register to the course using my email, Facebook or LinkedIn accounts. 2. As a par7cipant I can search for trainings for next year by topic and loca7on so that I create a year-long training plan. 3. As a trainer I want to manage class par7cipants. 4. As a trainer I need to upload par7cipant list so that they receive class materials as well as photos and links to books and ar7cles.
  75. 75. Acceptance tests in bdd GIVEN … WHEN … THEN …
  76. 76. Part 9 Collaborating with a development team
  77. 77. In a Head of a Product Owner You have split all the features into stories, es7mated them with the teams, start measuring velocity… and the data tells that you can’t do it by the deadline. What do you do? A)  Ignore the data and con7nue working B)  Try to shi= the deadline C)  Add people to the project D)  Make people work harder
  78. 78. Tracking Release Progress Time (sprints) Amount of work (points) rate of backlog change when you will release amount of work remaining
  79. 79. Managing Release Scope Time (sprints) Amount of work (points) Deadline MOVE THIS MANY POINTS TO NEXT RELEASE
  80. 80. Ingredients of Self-Organization 1.  High Alignment our goal is … 2.  Clear Constraints Here are some boundaries to follow … 3.  High Autonomy go and figure out how …
  81. 81. Alignment and Autonomy micro-management leadership chaos chaos
  82. 82. SPRINT PLANNING 101 Commitment-based PlanningPARTONE PARTTWO INITIAL SPRINT GOAL PRESENTED PLANNED CAPACITY DISCUSSED TOP PRODUCT BACKLOG ITEMS PRESENTED PBI REVIEWED ONE BY ONE NEEDED REFINEMENT HAPPENS ITEM ADDED TO SPRINT PLAN CONTINUE UNTIL TEAM SAYS “ENOUGH” SPRINT GOAL GETS ADJUSTED
  83. 83. Sprint Is Not Mini-Waterfalls analyze design test code Sprint Sprint Sprint Sprint
  84. 84. SCRUM IS NOT A SERIES OF MINI WATERFALLS Feature A Feature B PLANNED: A,B,C,D DONE: nothing DESIGN PROTO MORE CODING TESTING Sprint done wrong CODING Feature D Feature C (next sprint) PLANNED: A,B,C,D DONE A,B,D Sprint done right Discussion Point [PO + Dev Team]
  85. 85. Done. or Done-Done-Done? Feature A Feature B Feature D COOL: A,B AND D ARE DONE! CAN WE DEPLOY THEM NOW? (poker face) OK.. SO WHAT’S LEFT? 1. 2. … 10.
  86. 86. Agile Coach developer, scrum master, scrum trainer, free-rider Alexey KRIVITSKY www.agiletrainings.eu 1980 – present Kiev – Hamburg

×