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
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
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
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
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
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
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
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