This document summarizes a presentation on agile product discovery and requirements gathering. The presentation covered facilitating product discovery through personas, story maps, and user story splitting. It emphasized the importance of writing small, independent user stories and outlined techniques for splitting large stories, such as by workflow steps, business rules, major efforts, simple/complex parts, and more. The goal is to develop stories that are independently valuable and easily estimated.

1. Agile Product Discovery
Leading the Requirements Gathering
Process
Armond Mehrabian
PMI San Diego
September 26, 2012
1

2. Exercise – Who we are
Introductions
Timebox:
10 minutes
2

3. About the Speaker
 Armond Mehrabian
• Portofino Solutions, Inc.
• 24 years in the software development industry
• Enterprise Agile Coach since 2008
• amehrabian@portofinosolutions.com
• @armond_m
3

4. Agenda
 Introductions
 The Agile Project Manager
 Facilitating Product Discovery
 Personas
 Story Maps
 Estimation of Effort
 Q&A
4

5. The Agile Project Manager
5

6. Ag·ile
Adjective: Able to move quickly and easily, well coordinated and adaptable
Synonyms: active, nimble, quick, spry, alert
Antonym: lethargic, slow, clumsy, awkward
6
6

7. The Manifesto for Agile Software
Development - 2001
Kent Beck Ron Jeffries
Mike Beedle Jon Kern
Arie van Bennekum Brian Marick
Alistair Cockburn Robert C. Martin
Ward Cunningham Steve Mellor
Martin Fowler Ken Schwaber
James Grenning Jeff Sutherland
Jim Highsmith Dave Thomas
Andrew Hunt
7
7

8. Agile Principles – The Agile Manifesto
“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value
the items on the left more”
http://www.agilemanifesto.org
88

9. Pioneer Thought Leaders
9
9

10. Recent Thought Leadership
10
10

11. Scaling Agility Across the Enterprise
“A startup is a human institution
designed to deliver a new product or
service under conditions of extreme
uncertainty.
It has nothing to do with the size of
the company, sector of the economy
or industry.”
- Eric Ries
11
11

12. Focus has been on Delivery
Scrum is the most widely used Agile frameworks for teams.
We’ll see how it scales to the enterprise.
Value
Timebox
Team
1212

13. Driving Innovation
13

14. Driving Innovation
14

15. User Stories
User Stories are a tool for elaborating backlog items
User Stories represent
customer requirements
rather than document them
15

16. User Story Template
The “user voice” form focuses the team on value delivery
As a <role>
I can <activity>
So that <business value>
(Roles can be people, devices, or systems)
16

17. User Story: The 3 C’s
Written on card Details in Acceptance
or in tool and conversation tests confirm
may annotate with product the story
with notes owner correctness
 Verify that the report
As a customer, I is accurate
would like to see my What about peek usage  Verify that peek
power usage on a time? usage is clearly
indicated
daily basis, so I can Oh yeah, I’d like to know
understand how to when I’m using premium  Verify that the bill
total and its due
reduce my bill. pricing. date are indicated
3 C’s coined by Ron Jeffries
17

18. User Story Card Examples
As a Consumer, I want As an administrator, I can set
to be able to see my the consumer’s password
daily energy usage so security rules so that users
that I can lower my are required to create and
energy costs and usage retain secure passwords,
keeping the system secure.
As a utility Marketing Director, As a technical support member, I
I can present users with new want the user to receive a
pricing programs so that they consistent and clear message
are more likely to continue anywhere in the application so
purchasing energy from me. that they can fix the issue
without calling support.
See Agile Software Requirements by Dean Leffingwell for the Tendril case study and more examples
18

19. INVEST in a Good Story
INVEST acronym created by Bill Wake
19

20. Exercise
Form into teams of 5
 Choose a facilitator (Agile PM)
 Choose a Product Manager
 Get your supplies
Timebox:
15 minutes
20

21. Exercise
Choose a product to design
 Online Dating Service
 High School web site
 Apparel shopping site
 Health monitoring device
 Invent your own
Timebox:
15 minutes
21

22. Personas
22

23. Persona Template
Choose a Name (Alliteration help it be sticky)
Add an image (a conversation starter)
Who is this person? What are they looking for in
the product?
•Time at the job? •Financial Benefits?
•Knowledge of domain? •Increased Productivity?
•Full time/Part time worker? •Fewer Steps?
•Incentives? •More fun?
•Level of Engagement? •Easier to Use?
•Education Level?
23

24. Exercise
Create 3 personas
 Persona 1: uses the product all the time
 Persona 2: uses the product occasionally
 Persona 3: Makes decisions based on the data
Timebox:
15 minutes
24

25. Exercise
Describe the personas for your
product
 Who is this person
 What do they want from the product
Timebox:
15 minutes
25

26. Persona Template
Choose a Name (Alliteration help it be sticky)
Add an image (a conversation starter)
Who is this person? What are they looking for in
the product?
•Time at the job? •Financial Benefits?
•Knowledge of domain? •Increased Productivity?
•Full time/Part time worker? •Fewer Steps?
•Incentives? •More fun?
•Level of Engagement? •Easier to Use?
•Education Level?
26

27. User Story Maps
27

28. User Story Maps
 User Story Mapping is an Agile technique for
managing product backlogs developed by Jeff
Patton
 They give structure and context to user
stories.
 They describe the user’s experience with your
product
28

29. User Story Mapping
 A way of organizing and prioritizing user
stories.
 Show the relationship between stories and
their children
 Help explain the user experience
 Help you plan releases in complete and
valuable slices of functionality.
29

30. Building Story Maps
1. Take one persona and ask “What do you do
at work every day?”
• Scenarios
• Activities
• Business Processes
2. Walk “a day in the life” for each item in 1
• User tasks
• Sub Processes
3. Backup and retell the story
• Are there any variations or dead-ends?
30

31. Release 1 Release 1 Release 2
Release 2
31

32. Exercise
Create a story map for each
persona
 What are some tasks that they perform?
 What are the sub-tasks that the system must
perform on their behalf?
 What are the paths through a complete user
task.
Timebox:
10 minutes
32

33. User Story Splitting
33

34. INVEST in a Good Story
INVEST acronym created by Bill Wake
34

35. User Stories are Small (ideally <= 8 points)
Technical Functional
Spike Spike Split Story
35

36. Splitting User Stories
 Workflow Steps  Data Methods
 Business Rule  Defer System
Variations Qualities
 Major Effort  Operations
 Simple/Complex  Use Case
Scenarios
 Variations in Data
 Break Out a Spike
36

37. Split by Workflow Steps
Identify specific steps that a user takes to accomplish a workflow,
then implement the workflow in increments.
 ...I can publish pricing programs
to the customer’s In-Home
Display
As a utility, I want to
update and publish  ...I can send a message to the
pricing programs to customer’s web portal
my customer...  ...I can publish the pricing table
to a customer’s smart thermostat
37

38. Split by Business Rule Variations
Business rule variations often provide a straightforward splitting
scheme
...sort by zip code
As a utility, I can
...sort by home
sort customers by
demographics
different
demographics... ...sort by energy
consumption
38

39. Split by Major Effort
Split into several parts with the first requiring the most effort.
Adding more functionality can be done later one.
As a user, I want ...I want to use Time-of-
to be able to Use pricing...
select/change my
...I want to pre-pay for
pricing program
my energy...
with my utility
through my web …I want to enroll in
portal... Critical-Peak-Pricing ...
39

40. Split by Simple / Complex
Simplify! What’s the simplest version that can possibly work?
As a user, I
basically want a ...respond to the time
fixed price, but I and the duration of the
also want to be critical peak pricing event
notified of Critical- ...respond to emergency
Peak-Pricing events
events...
40

41. Split by Operations
Split by type of operation example: Create Read Update Delete
(CRUD)…
...I can sign up for an
account.
As a user, I can ...I can edit my account
manage my account settings.
... ...I can cancel my account.
…I can add more devices to
my account
41

42. Split by Use Case Scenarios
If use cases are used to represent complex interaction, the story can
be split via the individual scenarios
 Use Case/Story #1 (happy path):
Notify utility that consumer has
equipment
As a user, I can enroll
 Use Case/Story #2: Utility
in the energy savings
provisions equipment and data,
program through a notifies consumer
retail distributor ...
 Use Case/Story #3 (alternate
scenario): Handle data validation
errors
42

43. Split – If All Else Fails, Break out a Spike
 In some cases, a story may be
hard to estimate
– may be too large or overly
complex
– or perhaps the implementation
is poorly understood Technical Functional
Spike Spike
 In that case, build a technical or
functional spike to figure it out;
then split the stories based on
that result.
43

44. Questions?
44

45. My Contact Info
 Armond Mehrabian
 amehrabian@portofinosolutions.com
 Your feedback at
www.armondmehrabian.com/feedback
 (760) 354-9053
 Twitter: armond_m
 Skype: armond.mehrabian
45