Lean out your product backlog with Lean product Development and business analysis techniques - Pascal Van Cauwenberghe

Download Lean out your product backlog with Lean product Development and business analysis techniques - Pascal Van Cauwenberghe

Post on 08-May-2015




4 download

Embed Size (px)


<ul><li>1.Lean out your Product Backlog<br />Pascal Van Cauwenberghe<br />Nayima<br /></li></ul> <p>2. Here we are now.Entertain us.<br />Kurt Cobain, American Philosopher<br />3. Consultant. <br />Project Manager. <br />Games Maker.<br />His Blog: blog.nayima.be<br />NAYIMA<br />We make play work<br />4. And so it begins<br />Were going Agile!<br />5. Congratulations<br />6. What do I do now?<br />7. Write User Stories<br />8. A Vomit of User Stories<br />9. Prioritise User Stories<br />10. We need Business Value on each card<br />11. HELP!<br />12. There has to be a better way<br />13. Id like to have a chat with you about...<br />14. 1. Some Business Analysis tools<br />That Ive used the past 10 years<br />15. 2. Tell war stories<br />Projects where we used the tools<br />16. 3. Explain why we do this<br />17. 3. Explain why we do this<br />Before<br />After<br />18. 4. You may have to do some work<br />19. 5. Share some more wisdom from American philosophers<br />20. Who are your top 3 stakeholders?What is their #1 goal?<br />You have 2 mins <br />to share with your neighbour<br />21. Goal Table<br />Stakeholder, n: Role, Team or Organisation involved or affected by the project<br />Goal, n: What a stakeholder wants to achieve<br />Capability, n: Something we need to achieve the goal. Necessary, but maybe not sufficient<br />Test, n: A way to decide if a goal has been achieved<br />Measure, n: A way to determine how close we are to a goal<br />Risk, n: Negative consequences of achieving the goal<br />22. A Phone Company<br />23. Focus on goals not means<br />24. Quantify stakeholder goals<br />25. The Logical Thinking Process<br />26. The Logical Thinking Process<br />Intermediate Objectives Map<br />Prerequisite/<br />Transition Tree<br />How do we get there?<br />In small steps.<br />What is our goal?<br />What are we missing?<br />Future Reality Tree<br />Current Reality Tree<br />Would that work?<br />What could possibly go wrong?<br />Why dont we have <br />what we need?<br />Conflict Resolution Diagram<br />What could be done to resolve the <br />underlying fundamental conflict?<br />27. Using the Logical Thinking Process<br />Intermediate Objectives Map<br />Current Reality Tree<br />Conflict Resolution Diagram<br />Future Reality Tree<br />Prerequisite/<br />Transition Tree<br />Context Diagram<br />28. Phone Intermediate Objectives Map<br />Get request<br />Update billing<br />Add service<br />Perform request<br />Provision service<br />Confirm request<br />How difficult could it be?<br />29. A Phone Company<br />30. Derive capabilities from goals<br />31. Some customers seem to have the phone number of our CEO...<br />32. What are the criteria your organisation uses to select and prioritise work?<br />You have 2 mins to share with your neighbour<br />33. Party like its 1999<br />, American Philosopher<br />34. Its 1999<br />While people are getting worried about Y2K<br />35. Project E<br />Goal: Build an online bank that sells mortgage loans in Sweden<br />And then in other European countries<br />Constraint: integrate with Swedish government databases<br />Constraint: 2 developers<br />Constraint: the press conference for the launch is in 2.5 months<br />36. 37. What happened?<br />We launched on time<br />Full-featured frontend<br />Combinationof manual and automated processes<br />One country at first, then expanded to Europe<br />All manual processes were automated gradually as customer base grew<br />Money coming in invested in backoffice automation<br />38. Good looking frontend<br />Press conference<br />Ease of use<br />Curious customers <br />can ask for quote<br />Integration with Swedish government Databases<br />Implement Swedish Business Rules<br />Expand to other countries<br />Scale number of customers<br />39. Business Value Model<br />Diagram of effects<br />What are the important goals?<br />How will we achieve the goals?<br />What are our constraints?<br />This is our strategy<br />This is our definition of value<br />40. A Phone Company<br />41. For example<br />Leading<br />Lagging<br />Customer satisfaction<br />Successful transactions<br />Reliable process<br />Call center cost<br /># calls<br />Request confirmation<br />Customer loss<br />Regulations<br />42. Project Economic Framework<br />43. Using the Logical Thinking Process<br />Intermediate Objectives Map<br />Current Reality Tree<br />Conflict Resolution Diagram<br />Future Reality Tree<br />Prerequisite/<br />Transition Tree<br />Context Diagram<br />Business Value Model<br />Plan<br />44. Business Value Model == Hypothesis<br />Make reasoning &amp; assumptions explicit<br />Verify regularly and improve<br />45. PDCA cycle<br />46. Product Development cycle<br />47. Create a Business Value hypothesis<br />48. Verify and improve your Business Value hypothesis<br />Early and often<br />49. Coin an acronym and you have a profitable consulting business<br />Dave Nicolette, American philosopher<br />50. IDD<br />Irritation Driven Development<br />TM<br />51. IDD<br />You heard it here first<br />TM<br />52. Everybody participates in building the models<br />53. The Kano Model<br />Stupid features<br />Table stakes<br />Linear features<br />54. If I had asked my customers what they wanted, they would have said Faster horses<br />Henry Ford, American philosopher<br />55. The Kano Model<br />Stupid features<br />Table stakes<br />Linear features<br />Exciters<br />56. WOW! I didnt know you could do that!<br />57. The big print giveth.The small print taketh away<br />Tom Waits, American philosopher<br />58. What could possibly go wrong?<br />59. Political risk<br />One type of product is the responsibility of division A<br />Other type of product is the responsibility of division B<br />Division manager bonus is based on revenue of division<br />60. Find one risk of success on your project<br />You have 2 mins to share with your neighbour<br />61. What are the dangers of success?<br />62. The chief cause of problems is solutions<br />Eric Sevareid, American philosopher<br />63. When do we (finally) start writing User Stories?<br />We thought you were an Agile coach?<br />And cant we start coding yet?<br />64. Writing stories made easy<br />Goal<br />AS A...<br />TO ACHIEVE...<br />I NEED...<br />GOTCHAS<br />Stakeholder<br />Capability<br />Test and <br />measure<br />Risk<br />I KNOW I GOT<br />IT WHEN...<br />TO ACHIEVE ...<br />AS A ...<br />I NEED ...<br />PASSES<br />ITS DONE WHEN ...<br />TO NOT ACHIEVE ...<br />I NEED ... Another capability<br />65. User Story Carpaccio<br />Goal Table<br />Project Level Story<br />Project Level Story<br />Project Level Story<br />Project Level Story<br />Release Level Story<br />Release Level Story<br />Release Level Story<br />Release Level Story<br />Release Level Story<br />Iteration Level Story<br />Iteration Level Story<br />Iteration Level Story<br />Iteration Level Story<br />66. Derive detailed stories from goals<br />Step by step<br />67. Kanban board<br />TODO<br />BUSY<br />Accept<br />DONE<br />Iteration<br />Release<br />Value<br />68. Integrate analysis into your flow<br />From Value to Cash<br />69. Help! My developers have gone Kanban!<br />70. Conflict Resolution Diagram<br />Prerequisite 1<br />Requirement 1<br />Objective<br />Requirement 2<br />Prerequisite 2<br />71. Conflict Resolution Diagram<br />Detailed <br />estimates <br />and plans<br />Reliable long <br />term roadmap<br />Satisfy growing customer base<br />No estimates<br />No planning<br />Be more efficient<br />72. How would you solve this?<br />73. Conflict Resolution Diagram<br />Detailed <br />estimates <br />and plans<br />Reliable long <br />term roadmap<br />Satisfy growing customer base<br />Assumption: estimating is the only way<br />to determine the cost of a feature<br />No estimates<br />No planning<br />Be more efficient<br />74. What if<br />We didnt have to estimate to have a cost?<br />We didnt have to create detailed stories to estimate and plan?<br />But thats not possible, is it?<br />75. Conflict Resolution Diagram<br />Detailed <br />estimates <br />and plans<br />Set budget and<br />Build to budget<br />Reliable long <br />term roadmap<br />Satisfy growing customer base<br />No estimates<br />No planning<br />Be more efficient<br />76. Building the roadmap<br />Put stakeholder goals in the roadmap, not features<br />More implementation freedom<br />More meaningful for customers<br />Estimate the value of each goal in the roadmap<br />Decide how much you want to invest to realise the value <br />As a percentage of the capacity of the team<br />Create a roadmap based on value and budget<br />Not cost<br />77. Building the roadmap<br />Goal 2<br />Value/<br />Budget<br />Goal 1<br />Value / Budget<br />Goal 4<br />Value/Budget<br />Goal 1<br />Value / Budget<br />Goal 3<br />Value/<br />Budget<br />Release 2<br />Release 1<br />78. Implementing the roadmap<br />For each release, the product manager and team decide how to achieve goals, given the budget <br />Dont have to stick to individual budgets as long as release budget is respected<br />Constraints create a challenge<br />Which leads to more creativity<br />Monitor flow of stories and handle risks<br />79. Would you rather haggle<br />80. or solve problems?<br />81. Respectful Challenge<br />82. Make it a problem-solving exercise<br />Thats what were good at<br />83. Keep focus<br />Dont work on 1000 goals at the same time<br />84. Dont outrun your customers<br />Backlog<br />The Bottleneck<br />The Business<br />Operations<br />Dev team<br />85. Dont outrun your customers<br />The Bottleneck<br />Dev team<br />The Business<br />Operations<br />Backlog<br />6 releases <br />per year<br />2 releases <br />per year<br />86. 4 customers are faster than 1<br />The Bottleneck<br />Dev team<br />Backlog<br />Sales<br />Operations<br />Production<br />Finance<br />Audit<br />Customers<br />6 releases <br />per year<br />2 major releases <br />per year per group<br />87. We dont call them The BusinessWe call us We<br />Dev team<br />Backlog<br />Sales<br />Operations<br />Production<br />Finance<br />Audit<br />Customers<br />6 releases <br />per year<br />2 releases <br />per year per group<br />88. Integrate deeply with your customer<br />89. Yes, but! No, but!<br />90. Commonly heard objections<br />Weve spent 6 months on analysis already<br />Business Value is impossible to measure<br />This is waterfall analysis, its not agile<br />This is too hard<br />Doing this with the whole team is a waste of time<br />Its too structured<br />91. The Phone Company<br />Before<br />Already spent 2 months on analysis<br />Identified 60 features<br />2 years worth of work<br />We need web-based self-service<br />Reluctantly agreed to do a few days of analysis training<br />After<br />Only 10 out of those 60 features delivered value<br />Identified 4 new features crucial to the success of the project<br />25% of the value could be delivered within one month; no need for a web application<br />92. The Chemicals Company<br />Before<br />Asked consultancy to provide bid<br />Consultants did 3 months of analysis<br />Estimate: 9 months of development<br />Customer asked us for a second opinion<br />After<br />2 weeks to provide bid<br />Estimate: 3 months of development<br />Customer increased value by exchanging features during the project<br />Delivered one day early<br />93. The Transport Company<br />Before<br />A new team on their first Agile project<br />Two days of business analysis with the whole team<br />Arent we wasting too much time analysing?<br />Why are the developers here?<br />When can we start coding?<br />After<br />In production 3 months earlier than predicted<br />I cant believe we already released. Normally wed still be doing analysis.<br />Developers came up with a new use for existing data, with large financial and ecological benefits<br />94. The Transport Company<br />Before<br />Development teams deliver more, faster thanks to agile methods<br />Real bottleneck is test and deploy: several months between development and deployment<br />Delivering more is making things worse<br />No budget to improve test and deploy<br />After<br />Every agile project has quantified value<br />Cost of deployment delay becomes visible: millions per month<br />Cost of improving test and deploy is insignificant compared to cost of delay<br />Started test and deploy improvement<br />95. To summarize<br />These are the only things you need to know to pass the test<br />96. Just remember<br />Focus on stakeholder goals, not means<br />Model and measure value<br />Apply the science of product development and systems thinking to generate questions<br />Tap into everyones creativity<br />Analyse just-in-time using pull<br />Make it a problem-solving exercise<br />Theres a lot more where this came from<br />97. Business Analysis Body of Knowledge (BABOK)<br />International Institute of Business Analysts (IIBA)<br />www.theiiba.org<br />98. From the BABOK<br />Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.<br />99. The Agile Extension to the BABOK<br />The Agile extension gives guidance on how to perform business analysis on Agile projects<br />Overview available on IIBA website<br />We need your input and review<br />Yahoo group: Agile_BA_Requirements<br />100. I must say I find television very educational. The minute somebody turns it on, I go into the other room and read a book <br />Groucho Marx, American philosopher<br />101. If you want to know more<br />102. 103. Merci<br />Thank You<br />Dank u<br />104. If you want to know more<br />www.agilecoach.net<br />www.nayima.be<br />blog.nayima.be<br /></p>