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.

Requirements Simplified Rod Hardman


Published on

Requirements Simplified
a talk for Product Camp Toronto, May 2010
Rod Hardman

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

Requirements Simplified Rod Hardman

  1. 1. Requirements Simplified OR HOW TO GET YOUR ENGINEERS TO SPEND MORE TIME CREATING WHAT CUSTOMERS REALLY WANT... ROD HARDMAN May 30, 2010 – Ted Rogers School of Management, Ryerson University
  2. 2. Welcome to Hell
  3. 3. In 10,000 years our requirements will not be retold around campfires...
  4. 4. In 10,000 years our requirements will not be retold around campfires... Our Stories will.
  5. 5. In Lean/Agile (especially XP and Scrum), stories are the requirement gathering tool of choice
  6. 6. Confession
  7. 7. I I’m a Hardware Guy
  8. 8. Stories User’s Needs Product Description Planning Items An Mechanism for Conversation
  9. 9. Stories: have a title a description: As a [type of user] I want to [perform some task] so that I can [reach some goal] Add Additional details notes, specifications, or sketches and acceptance criteria (how do we know when we’re done?)
  10. 10. Title: Look up Dog Parks As a Dog Owner I want to Look up Dog Parks So that I can find a Park in my area for my Dog
  11. 11. Build Out User “Profiles”
  12. 12. A collection of stories for a product is referred to as the product backlog The backlog is prioritized such that the most valuable items are highest
  13. 13. Why Use Stories? Minimum Viable Description Develop a Shared understanding - Quickly How fast can you put a product in front of a customer Defence - Protect your funding
  14. 14. Innovation Games Luke Holmann Product Box: Participants imagine that theyʼre selling a vendorʼs product at a tradeshow, retail outlet, or public market. Participants use plain cardboard boxes, glue, paint, crayons, and other scraps and knickknacks to design a product box that they would buy. Prune the Product Tree: A very large tree (representing a system or product) is drawn on a whiteboard. Thick limbs represent major areas of functionality within the system. The edge of the tree—its outermost branches—represent the features available in the current release of the product. Participants write new features on several index cards that are shaped like leaves, and then they place these feature-leaves onto the tree, revealing which branches (product features) are important to customers for future improvements Buy a Feature: Participants see a list of proposed product features and a cost (expressed as development effort or street-level pricing) associated with each. Each participant “buys” a desirable feature; participants may also pool resources to buy features too expensive to be purchased with individual funds. Luke Hohmann, Innovation Games: Creating Breakthrough Products through Collaborative Play (Boston: Addison-Wesley, 2007),
  15. 15. ABC+
  16. 16. A bsolute B est C ost +
  17. 17. A bsolute B est C ost + (Plus Factors)
  18. 18. (Plus Factors) Features or Attributes That a customer will specifically pay for
  19. 19. Great Places for More • • •
  20. 20. Requirements Simplified Rod Hardman