leading agile product discovery
DESCRIPTION
This presentation was made by Armond Mehrabian at the PMI conference on 9-26-2012 in San Diego.TRANSCRIPT
1
Agile Product Discovery Leading the Requirements Gathering
Process
Armond Mehrabian
PMI San Diego
September 26, 2012
2
Exercise – Who we are
Introductions
Timebox:
10 minutes
3
About the Speaker
Armond Mehrabian
• Portofino Solutions, Inc.
• 24 years in the software development industry
• Enterprise Agile Coach since 2008
• @armond_m
4
Agenda
Introductions
The Agile Project Manager
Facilitating Product Discovery
Personas
Story Maps
Estimation of Effort
Q & A
5
The Agile Project Manager
6 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
7
The Manifesto for Agile Software
Development - 2001
7
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
8
“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:
8
Agile Principles – The Agile Manifesto
http://www.agilemanifesto.org
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”
9
Pioneer Thought Leaders
9
10
Recent Thought Leadership
10
11
Scaling Agility Across the Enterprise
11
“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
12
Focus has been on Delivery
12
Scrum is the most widely used Agile frameworks for teams.
We’ll see how it scales to the enterprise.
Team
Value Timebox
13
Driving Innovation
14
Driving Innovation
15
User Stories
User Stories are a tool for elaborating backlog items
User Stories represent
customer requirements
rather than document them
16
User Story Template
(Roles can be people, devices, or systems)
The “user voice” form focuses the team on value delivery
As a <role> I can <activity>
So that <business value>
17
User Story: The 3 C’s
Written on card
or in tool and
may annotate
with notes
Details in
conversation
with product
owner
Acceptance
tests confirm
the story
correctness
As a customer, I
would like to see my
power usage on a
daily basis, so I can
understand how to
reduce my bill.
What about peek usage
time?
Oh yeah, I’d like to know
when I’m using premium
pricing.
Verify that the report
is accurate
Verify that peek
usage is clearly
indicated
Verify that the bill
total and its due
date are indicated
3 C’s coined by Ron Jeffries
18
As a utility Marketing Director,
I can present users with new
pricing programs so that they
are more likely to continue
purchasing energy from me.
User Story Card Examples
As a Consumer, I want
to be able to see my
daily energy usage so
that I can lower my
energy costs and usage
As an administrator, I can set
the consumer’s password
security rules so that users
are required to create and
retain secure passwords,
keeping the system secure.
As a technical support member, I
want the user to receive a
consistent and clear message
anywhere in the application so
that they can fix the issue
without calling support.
See Agile Software Requirements by Dean Leffingwell for the Tendril case study and more examples
19
INVEST in a Good Story
INVEST acronym created by Bill Wake
20
Exercise
Form into teams of 5
Choose a facilitator (Agile PM)
Choose a Product Manager
Get your supplies
Timebox:
15 minutes
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
22
Personas
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?
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
25
Exercise
Describe the personas for your
product
Who is this person
What do they want from the product
Timebox:
15 minutes
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?
27
User Story Maps
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
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.
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?
31
Release 1
Release 2
Release 1
Release 2
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
33
User Story Splitting
34
INVEST in a Good Story
INVEST acronym created by Bill Wake
35
User Stories are Small (ideally <= 8 points)
Technical
Spike
Functional
Spike Split Story
36
Splitting User Stories
Workflow Steps
Business Rule
Variations
Major Effort
Simple/Complex
Variations in Data
Data Methods
Defer System
Qualities
Operations
Use Case
Scenarios
Break Out a Spike
37
As a utility, I want to
update and publish
pricing programs to
my customer...
...I can publish pricing programs
to the customer’s In-Home
Display
...I can send a message to the
customer’s web portal
...I can publish the pricing table
to a customer’s smart thermostat
Split by Workflow Steps
Identify specific steps that a user takes to accomplish a workflow,
then implement the workflow in increments.
38
As a utility, I can
sort customers by
different
demographics...
...sort by zip code
...sort by home
demographics
...sort by energy
consumption
Split by Business Rule Variations
Business rule variations often provide a straightforward splitting
scheme
39
...I want to use Time-of-
Use pricing...
...I want to pre-pay for
my energy...
…I want to enroll in
Critical-Peak-Pricing ...
As a user, I want
to be able to
select/change my
pricing program
with my utility
through my web
portal...
Split by Major Effort
Split into several parts with the first requiring the most effort.
Adding more functionality can be done later one.
40
...respond to the time
and the duration of the
critical peak pricing event
...respond to emergency
events
As a user, I
basically want a
fixed price, but I
also want to be
notified of Critical-
Peak-Pricing
events...
Split by Simple / Complex
Simplify! What’s the simplest version that can possibly work?
41
As a user, I can
manage my account
...
...I can sign up for an
account.
...I can edit my account
settings.
...I can cancel my account.
…I can add more devices to
my account
Split by Operations
Split by type of operation example: Create Read Update Delete
(CRUD)…
42
As a user, I can enroll
in the energy savings
program through a
retail distributor ...
Use Case/Story #1 (happy path):
Notify utility that consumer has
equipment
Use Case/Story #2: Utility
provisions equipment and data,
notifies consumer
Use Case/Story #3 (alternate
scenario): Handle data validation
errors
Split by Use Case Scenarios
If use cases are used to represent complex interaction, the story can
be split via the individual scenarios
43
In some cases, a story may be
hard to estimate
– may be too large or overly
complex
– or perhaps the implementation
is poorly understood
In that case, build a technical or
functional spike to figure it out;
then split the stories based on
that result.
Split – If All Else Fails, Break out a Spike
Technical
Spike
Functional
Spike
44
Questions?
45
My Contact Info
Armond Mehrabian
Your feedback at
www.armondmehrabian.com/feedback
(760) 354-9053
Twitter: armond_m
Skype: armond.mehrabian