Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à From Unclear and Unrealistic Requirements to Achievable User Stories
Similaire à From Unclear and Unrealistic Requirements to Achievable User Stories (20)
Plus de TechWell
Plus de TechWell (20)
Dernier
Dernier (20)
From Unclear and Unrealistic Requirements to Achievable User Stories
- 3. 5/30/16 1 FROM UNCLEAR AND UNREALISTIC REQUIREMENTS TO ACHIEVABLE USER STORIES Jamie Lynn Cooke CSM, CSPO Both Hemispheres, LLC e-Builder © Both Hemispheres LLC 2016 Slide 2 "What do you want the system to do?" § Loaded question…. § Wide variety of possible solutions to address business needs § Responses can be anything from fuzzy, high level requirements to extremely detailed technical features § Heavily depends on who is answering the question
- 4. 5/30/16 2 © Both Hemispheres LLC 2016 Slide 3 In an ideal world, the Product Owner: § Intimately understands the business requirements § Accurately represents the perspectives and priorities of all stakeholders § Is able to articulate requirements as realistic business-driven capabilities § Establishes clear priorities and understands that not every feature is mission-critical § Is open to team feedback and adjustments § Understands and values Agile thinking © Both Hemispheres LLC 2016 Slide 4 In reality, Product Owners vary in their: § Scope of knowledge § Depth of knowledge § Points of reference § Experience with Agile methods § Technical expertise § Flexibility § Decisiveness § Empowerment and authority § (Availability)
- 5. 5/30/16 3 © Both Hemispheres LLC 2016 Slide 5 Four common Product Owner challenges: 1. The “big picture” product owner 2. The “aspiring developer” product owner 3. The “kid in a candy store” product owner 4. The “see saw” product owner Which is your most common challenge? © Both Hemispheres LLC 2016 Slide 6 The “Big Picture” Product Owner: § Epic thinking § High level descriptions of requirements § Unable to describe (or decide on) specific system behavior § May be limited by: ú Perspective ú Depth of knowledge ú Fear of being responsible for decisions ú ….
- 6. 5/30/16 4 © Both Hemispheres LLC 2016 Slide 7 Example: Grocery Home Delivery Service As a customer, I want to be able to order groceries online and have them delivered to my home so that I do not need to spend time at the supermarket. Priority: High As a store manager, I want to get enough information for staff to accurately fill online customer orders so that I can avoid complaints and returns. Priority: High As an executive, I want to use online orders to expand our customer base by 12% so that we can increase our profits. Priority: High © Both Hemispheres LLC 2016 Slide 8 Breaking Down the Requirements: First Technique: Ask for the story § Tell me about the “best case”…. ú A typical customer ordering experience ú How the warehouse fills orders ú Acceptable forms of payment ú …. § Tell me about the exceptions…. ú Unusual customer orders ú What you do when items are out of stock ú Handling returns and replacement items ú ….
- 7. 5/30/16 5 © Both Hemispheres LLC 2016 Slide 9 Breaking Down the Requirements: First Technique: Ask for the story § Forces practical thinking and tangible outcomes § Solidifies expectations § Gives incidental details § Exposes knowledge gaps § Establishes priorities § Describes acceptable alternative options © Both Hemispheres LLC 2016 Slide 10 Breaking Down the Requirements: Second Technique: Ask leading questions § Can customers place same day orders? What is the cut off time for orders? § Is there a minimum order amount? § Is there a time limit for changing or cancelling orders? § How is realtime product and inventory information maintained? § Does the warehouse need special packing materials? § Are delivery vans equipped with refrigerated storage? § What do you do when….
- 8. 5/30/16 6 © Both Hemispheres LLC 2016 Slide 11 Breaking Down the Requirements: Second Technique: Ask leading questions § Challenges the Product Owner’s perspective § Engages the Product Owner in finding solutions § Forces practical thinking and tangible outcomes § Distinguishes expected system behavior from exception cases § Solidifies expectations § Gives incidental details § Exposes knowledge gaps § Describes acceptable alternative options © Both Hemispheres LLC 2016 Slide 12 Breaking Down the Requirements: Third Technique: Detail the acceptance criteria § Get measurable definitions of success for: ú The customer Selecting items to order Placing the order Scheduling delivery Paying for the order ú The warehouse Filling the order Packing the order Handling damaged or out of stock items ú The delivery driver Getting to the customer location Finding the order on the truck Confirming the order with the customer Handling returns, damaged items, missing items
- 9. 5/30/16 7 © Both Hemispheres LLC 2016 Slide 13 Breaking Down the Requirements: Third Technique: Detail the acceptance criteria § Quantifies the expectations § Forces realistic thinking § Provides boundaries § Establishes priorities § Gives incidental details § Identifies acceptable alternatives © Both Hemispheres LLC 2016 Slide 14 Breaking Down the Requirements: Fourth Technique: Split the story For each story, use these approaches to elicit the details: § Go through workflow steps by role § Identify exceptions and variations in • User types • Business rules • Data types • Platforms § Devolve compound statements § Clarify ambiguous terms like “manage” or “process”
- 10. 5/30/16 8 © Both Hemispheres LLC 2016 Slide 15 Breaking Down the Requirements: Fourth Technique: Split the story Patterns for Splitting User Stories: http://agileforall.com/patterns-for-splitting-user- stories/ 10 Useful Strategies for Breaking Down Large User Stories: http://blog.agilistic.nl/10-useful-strategies-for- breaking-down-large-user-stories-and-a- cheatsheet/ © Both Hemispheres LLC 2016 Slide 16 Breaking Down the Requirements: Fourth Technique: Split the story § Forces detailed thinking § Isolates individual requirements § Identifies commonalities and trends § Highlights differences § Establishes relative priorities § Gives incidental details § Identifies acceptable alternatives
- 11. 5/30/16 9 © Both Hemispheres LLC 2016 Slide 17 The “Aspiring Developer” Product Owner: § Technical view of the solution § Highly detailed system behavior § Minimal reference to business requirements § May be limited by: ú Perspective ú Scope and depth of knowledge ú Previous project challenges ú …. © Both Hemispheres LLC 2016 Slide 18 Example: Grocery Home Delivery Service As a customer, I want to be able to order groceries through a browser or mobile device so that I can place an order wherever I am. Priority: High As a warehouse manager, I want to use our existing fleet of refrigerated trucks so that I do not need to budget for new equipment. Priority: High As a delivery driver, I want to have a wireless device for customer signatures so that I can complete the order at their door. Priority: High
- 12. 5/30/16 10 © Both Hemispheres LLC 2016 Slide 19 Example: Grocery Home Delivery Service As a developer, I want the home grocery delivery payments to use our current credit card processing system so that I do not need to build and maintain customized payment methods. Priority: High © Both Hemispheres LLC 2016 Slide 20 Moving from Technical to Business Requirements: Eliminating the obvious question: What if the product does not have front end users, e.g. systems integration, and technical stories are required? See Mike Cohn’s response: https://www.mountaingoatsoftware.com/ blog/writing-user-stories-for-back-end- systems
- 13. 5/30/16 11 © Both Hemispheres LLC 2016 Slide 21 Moving from Technical to Business Requirements: First Technique: Build up the story § Acknowledge the validity of the technical requirements § Refocus the discussion on the business story ú Try asking for the “best case” and exception scenarios (if the Product Owner can easily switch perspectives) ú If not, work upward from the stories provided, e.g. You said that you want customers to be able to order groceries through a browser: What will they see when they enter the website? How will they choose the products they want? What happens when they select [Place Order]? © Both Hemispheres LLC 2016 Slide 22 Moving from Technical to Business Requirements: First Technique: Build up the story § Works from the Product Owner’s point of reference § Forces end user thinking § Puts technical requirements in context § Solidifies expectations § Gives incidental details § Exposes knowledge gaps § Establishes priorities § Describes acceptable alternative options
- 14. 5/30/16 12 © Both Hemispheres LLC 2016 Slide 23 Moving from Technical to Business Requirements: Second Technique: Leverage Existing Systems § Walk through similar solutions from the end user perspective: ú What features do they like? ú What features are essential, “nice to have” and unnecessary? ú What would they improve? § Compare and contrast multiple solutions § Incorporate technical requirements in the story where relevant This technique can also be used to solidify thinking for the “Big Picture” Product Owner © Both Hemispheres LLC 2016 Slide 24 Moving from Technical to Business Requirements: Second Technique: Leverage Existing Systems
- 15. 5/30/16 13 © Both Hemispheres LLC 2016 Slide 25 Moving from Technical to Business Requirements: Second Technique: Leverage Existing Systems © Both Hemispheres LLC 2016 Slide 26 Moving from Technical to Business Requirements: Second Technique: Leverage Existing Systems § Aligns with technical perspective § Forces end user thinking § Solidifies expectations § Gives incidental details § Identifies priorities § Describes acceptable alternative options
- 16. 5/30/16 14 © Both Hemispheres LLC 2016 Slide 27 Moving from Technical to Business Requirements: Third Technique: Ask for Subject Matter Expert Consultation § Caveat: Tread lightly § Desire is to supplement Product Owner knowledge not to replace or undermine it § Request specific knowledge areas: ú Customer service ú Warehouse ú Store management ú End users § Defer to Product Owner for decisions © Both Hemispheres LLC 2016 Slide 28 Moving from Technical to Business Requirements: Third Technique: Ask for Subject Matter Expert Consultation § Forces end user thinking § Puts technical requirements in context § Solidifies expectations § Gives incidental details § Establishes priorities § Describes acceptable alternative options § Retains Product Owner authority
- 17. 5/30/16 15 © Both Hemispheres LLC 2016 Slide 29 The “Kid in a Candy Store” Product Owner § Everything is critical priority § Waterfall thinking § Limited understanding of relative business value § No incentive to prioritize § May be limited by: ú Perspective ú Scope and depth of knowledge ú Fear of making decisions ú Fear of failure ú …. © Both Hemispheres LLC 2016 Slide 30 Example: Grocery Home Delivery Service Xxxx xxxxxx xxxxxx xx xxxx xxx xxxxx xx xxxx xxxx xxxx xxx xxxx xxxxx xxx xxxxx. Priority: Critical Xxxx xxxxxx xxxxxx xx xxxx xxx xxxxx xx xxxx xxxx xxxx xxx xxxx xxxxx xxx xxxxx. Priority: Critical Xxxx xxxxxx xxxxxx xx xxxx xxx xxxxx xx xxxx xxxx xxxx xxx xxxx xxxxx xxx xxxxx. Priority: Critical Xxxx xxxxxx xxxxxx xx xxxx xxx xxxxx xx xxxx xxxx xxxx xxx xxxx xxxxx xxx xxxxx. Priority: Critical Xxxx xxxxxx xxxxxx xx xxxx xxx xxxxx xx xxxx xxxx xxxx xxx xxxx xxxxx xxx xxxxx. Priority: Critical Xxxx xxxxxx xxxxxx xx xxxx xxx xxxxx xx xxxx xxxx xxxx xxx xxxx xxxxx xxx xxxxx. Priority: Critical
- 18. 5/30/16 16 © Both Hemispheres LLC 2016 Slide 31 The “See Saw” Product Owner § Cannot make (or stick to) decisions on priorities § Another example of waterfall thinking § Limited business knowledge (or understanding of relative business value) § No incentive to prioritize § May be limited by: ú Fear of making decisions ú Fear of failure ú Perspective ú Scope and depth of knowledge ú …. © Both Hemispheres LLC 2016 Slide 32 Example: Grocery Home Delivery Service As a customer, I want to be able to see the complete grocery list before I pay so that I can confirm that all required items are included. Medium High Priority: High Low As a store manager, I want to product numbers included on each order so that staff can find them in the warehouse. Priority: High Critical As an delivery driver, I want refrigerated items listed together so that I can get all of them out of the truck at the same time. High Priority: Medium High
- 19. 5/30/16 17 © Both Hemispheres LLC 2016 Slide 33 Getting to Realistic Priorities: First Technique: Reinforce Agile Thinking § Fear of failure in priority setting is often based on waterfall thinking § Assure Product Owner that: ú Priority setting in an Agile environment is an emergent process ú There will be ongoing opportunities to review built features and to adjust priorities as needed ú They control the definition of “done” and approval for release © Both Hemispheres LLC 2016 Slide 34 Getting to Realistic Priorities: First Technique: Reinforce Agile Thinking § Combats the “once chance to get it right” mindset § Switches the focus from prioritization to requirements clarification § Encourages collaboration § Builds trust
- 20. 5/30/16 18 © Both Hemispheres LLC 2016 Slide 35 Getting to Realistic Priorities: Second Technique: Leverage the MVP § Identifying the Minimum Viable Product (MVP) assures the Product Owner that all essential features will be included § Frees the Agile team to prioritize by the: ú Amount of investigation and experimentation required ú Highest risk ú Longest lead time ú Etc. © Both Hemispheres LLC 2016 Slide 36 Getting to Realistic Priorities: Second Technique: Leverage the MVP § Removes business-driven prioritization from the equation § Removes the Product Owner’s risk of making the wrong decision § Switches the focus to requirements clarification § Encourages collaboration § Builds trust
- 21. 5/30/16 19 © Both Hemispheres LLC 2016 Slide 37 Getting to Realistic Priorities: What if the Product Owner still insists on prioritizing by business value? Quick Answer: Assign a business value to each story and order them top down from the highest business value story to the lowest It is not always that simple…. © Both Hemispheres LLC 2016 Slide 38 Getting to Realistic Priorities: May be achievable if the Product Owner can quantify business value in: § Reduction of cost § Reduction of time § Reduction of risk § Customer/Stakeholder satisfaction § Elimination of waste § Reduction of complexity § Improvement to quality
- 22. 5/30/16 20 © Both Hemispheres LLC 2016 Slide 39 Getting to Realistic Priorities: Where do these business value quantifications come from? § Baseline metrics? § Empirical evidence? § Extensive market research? § Speculation and educated guesses? More often than not, they are based on the Product Owner’s perspective © Both Hemispheres LLC 2016 Slide 40 Getting to Realistic Priorities: Assigning business values to user stories is an especially controversial topic in the Agile world: § “Business value prioritization can only be done at the epic level” § “You should prioritize the highest business value features first, then write user stories for each” The issue may be in focusing too heavily on the word “priorities”
- 23. 5/30/16 21 © Both Hemispheres LLC 2016 Slide 41 Getting to Realistic Priorities: Third Technique: Remove “Priority” Language § Replace emotive terms like “critical priority” and “low priority” by: ú Requesting numerical top-down ordering instead of priorities ú Using “planning poker” for business value assignment (extremely effective when the Product Owner is working with other SMEs) § If the Product Owner still insists on using priorities, try asking for relative priorities like “more critical” and “most critical” © Both Hemispheres LLC 2016 Slide 42 Getting to Realistic Priorities: Third Technique: Remove “Priority” Language § Removes the pressure of making language based priority judgment calls, e.g. what should be “critical” versus “high” § Does not devalue the stories at the bottom of the backlog by calling them “low priority” § Focuses the team on the order of delivery instead of the terminology
- 24. 5/30/16 22 © Both Hemispheres LLC 2016 Slide 43 Getting to Realistic Priorities: Fourth Technique: Select the “Top Five” § Conduct a role playing scenario: Executive management will only allocate an initial budget for building five stories. They want to see a demonstration of the five stories fully built and fully tested to determine if additional funding should be allocated. Which five stories would you choose and why? Put the selected stories at the top of the backlog and then repeat the exercise with the remaining stories, putting the newly selected stories directly beneath the previous ones © Both Hemispheres LLC 2016 Slide 44 Getting to Realistic Priorities: Fourth Technique: Select the “Top Five” § Forces: ú Critical thinking ú Decision-making ú Justification of selected stories § Removes the challenge of trying to order the entire backlog § Answering the “why” question can elicit key details and insights into each story selected (and not selected)
- 25. 5/30/16 23 © Both Hemispheres LLC 2016 Slide 45 Getting to Realistic Priorities: Fifth Technique: Select the “Bottom 10%” § Conduct a role playing scenario: Executive management cuts the product budget by 10%. You need to remove 10% of the stories from the backlog. Which stories would you choose to cut and why? Put the cut stories at the bottom of the backlog and then repeat the exercise with the remaining stories, putting the newly cut stories on top of the previous ones © Both Hemispheres LLC 2016 Slide 46 Getting to Realistic Priorities: Fifth Technique: Select the “Bottom 10%” § Minimizes the severity of the decision § Forces: ú Critical thinking ú Justification of eliminated stories § Removes the challenge of trying to order the entire backlog § Answering the “why” question can elicit key details and insights into each story removed (and the ones that remain)
- 26. 5/30/16 24 © Both Hemispheres LLC 2016 Slide 47 Quick Plug for My Books § Agile Productivity Unleashed: Proven Approaches for Achieving Real Productivity Gains in Any Organization § Agile: An Executive Guide: Real Results from IT budgets § Everything You Want to Know about Agile: How to Get Agile Results in a Less-than-Agile Organization § The Power of the Agile Business Analyst: 30 Surprising Ways a Business Analyst Can Add Value to Your Agile Development Team § PRINCE2 Agile™: An Implementation Pocket Guide (coming) © Both Hemispheres LLC 2016 Slide 48 The Goal: Achievable User Stories Questions?
- 27. 5/30/16 25 © Both Hemispheres LLC 2016 Slide 49 The Goal: Achievable User Stories If you want to contact me: § Am available after this session § Am also holding one-on-one speaker sessions on Thursday § Send me your questions: jamie@realproductivitygains.com Thank you for your time!