Successfully reported this slideshow.
Requirements Simplified
OR HOW TO GET YOUR ENGINEERS TO SPEND
 MORE TIME CREATING WHAT CUSTOMERS
            REALLY WANT......
Welcome to Hell
In 10,000 years our
requirements will not be
retold around campfires...
In 10,000 years our
requirements will not be
retold around campfires...

Our Stories will.
In Lean/Agile
(especially XP and Scrum),
stories are the requirement
gathering tool of choice
Confession
I

    I’m a
Hardware Guy
Stories
                             User’s Needs
  Product Description

                        Planning Items


       A...
Stories:
have a title
a description:
   As a [type of user]
   I want to [perform some task]
   so that I can [reach some ...
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
Build Out User “Profiles”
A collection of stories for a
product is referred to as the
product backlog
The backlog is prioritized such
that the most ...
Why Use Stories?
            Minimum Viable Description

     Develop a Shared understanding - Quickly

How fast can you p...
Innovation Games
                                        Luke Holmann
  Product Box: Participants imagine that theyʼre sel...
ABC+
A bsolute
B est
C ost
+
A bsolute
B est
C ost
+ (Plus Factors)
(Plus Factors)

Features
           or Attributes


That a customer will specifically pay for
Great Places for More

• www.infoq.com
• www.AgileProductDesign.com
• http://innovationgames.com/
Requirements
  Simplified

   Rod Hardman
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
Upcoming SlideShare
Loading in …5
×

PCT2010 - Requirements Simplified

2,119 views

Published on

Creating effective Product Requirements documents takes a lot of effort, often undermining whether they actually get done. Much of what is written is rarely implemented and the details are not always static as they change when the team learns what it really wants. This session would sort through what is really needed in a Requirements document focusing on what actually gets done.

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

  • Be the first to like this

PCT2010 - Requirements Simplified

  1. 1. Requirements Simplified OR HOW TO GET YOUR ENGINEERS TO SPEND MORE TIME CREATING WHAT CUSTOMERS REALLY WANT... ROD HARDMAN www.productcamp.org/toronto 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 • www.infoq.com • www.AgileProductDesign.com • http://innovationgames.com/
  20. 20. Requirements Simplified Rod Hardman

×