Lean/Agile 101

Story Exploration Part 1

August 21st, 2014

Agile Transformation Inc.

Jeff Anderson
thomasjeffreyandersontwin@gmail.com
 The lifecycle and evolution of a story…

Release • Outline scope by starting a story map

Planning
• Extend the story map to include a complete list
of stories required for the next Sprint
Sprint
Preparation
• Produce a story sketch for each story

• Define explicit, testable

acceptance criteria and
scenarios for each story
• Validate each story against
acceptance criteria
Next Sprint

Sprint Delivery

• Track progress of story analysis, delivery and

validation on an Kanban system

Measure using a cumulative flow diagram

Introduction to user stories
 User Stories are the basic units of work delivered in an iteration
Ready for
S Estimation
M
As a: Who?
A
I want: What? R
T
Given: <Preconditions>
So that: Why?
Story Detail

When: <Triggers>

Then: <Outcomes>

High Level Acceptance

Few Words Key Scenarios
Structure Criteria

Product Backlog Refinement

User Stories should be estimated just in time for the iteration that will deliver them and have
just enough detail to be estimated
4
User Stories are all about the users, and supporting their needs / wants

Imagine you are building a new product – for example,

a mobile device for children

Who are the users that you should consider?

5
User Stories are also hierarchical
“Themes”
Over arching business capability or long lived business
process
e.g. Go to work
“Epics ”
Business or Architecture goals to be realized by the
system
e.g. Get ready for work
“Activities”
User actions that are meaningful within the context of a
business goal
e.g. get dressed
“User Story”
Meaningful unit of work that can be completed
by a team within an iteration, typically one
distinct function
e.g. wear socks
“Tasks”
Reusable procedure or sub-routine which
doesn't belong on the map
6 e.g. Lift right leg
Epics come in two types: Business and Architecture
What are Business Epics?
• Represent a set of high level requirements that are typically end-to-end customer
focused outcomes
• Need to be refined into smaller discrete units of business value (User Stories) that can
be analyzed, estimated, developed and tested
• Often represent business capabilities or end-to-end business processes to describe
the high level scope and major objectives for a project

Describe a business outcome/benefit As a… Credit Card Holder

Capture the major functionality needed to I want to… have a 24/7, multi-
channel, self-service portal to
achieve the outcome
my account
Focused on a set of customer/user
So that… I can view and manage
segments
my account
Can be decomposed into a set of stories
7
Epics come in two types: Business and Architecture
What are Architecture Epics?
• Represent an end-to-end vertical slice of the technical solution required to realize one
or more Business Epics
• Need to be refined into smaller discrete units of business value (User Stories) that can
be analyzed, estimated, developed and tested
• Typically considered architecturally significant to help drive out key technology
decisions and identify cross cutting concerns with the systems/solutions involved

Aligned with one or more Business Epics “Access account via multiple
channels”
Can be further elaborated into a set of • Person accesses account
solution options online view webpage
• Person accesses account
Identify an architecturally significant via mobile device
scenario • Person phones in to
access account

8
Several guiding principles have been established for gauging the quality of a
User Story – the INVEST principles
Independent A story is structured to minimize dependency on other work tickets

Negotiable A story allows further refinement of scope to provide options around timing and cost

Valuable A story has concrete business value or an inherent investment value

Estimate A story has sufficient scope and design definition to enable coarse estimation

Small A story is small enough to be completed within an iteration

Testable A story is testable by itself and has clear acceptance criteria associated with it

The 3 C’s:
• A Card represents the physical capture of the user story
• A Conversation represents a “promise for a conversation” between the team and other stakeholders
• A Confirmation represents the acceptance criteria that provide clear conditions of completion

9
Acceptance Criteria provide a set of conditions that a User Story must meet to
be considered done
Use the following guide when writing acceptance criteria:

Keep independent of implementation/technology

Keep relatively high level (not every detail needs to be in writing) SPECIFIC

Make acceptance criteria SMART MEASURABLE

Include multiple perspectives when writing (e.g., business, technology)

ACHIEVABLE

RELEVANT
Avoid ambiguous language

TIME-BOUND
Avoid subjective/judgmental language (e.g., better, good, allowable)

Avoid generalizations (e.g., all the time, never, everyone, always)

Acceptance criteria bound the story, letting developers know when to stop developing, and
testers know when to stop testing
10
Email payments example:

Story: Payment Center compares interact RECON file to Payment Center

Transaction

Story summary: As a BCAU operator, and an Interac Operator, I want

payment center to compare the interact reconciliation file with the payment
center transaction record and generate an exception report if there are
discrepancies, so I can fix any discrepancies that arise

Acceptance criteria:
1. The report is not generated if there are no discrepancies
2. The report includes Discrepancy items which contain original transaction,
discrepancy details, (e.g.: amount)
3. The report is sent to EAA for forwarding to various departments
4. The report is generated daily

11
User Stories can be further elaborated into key business / user scenarios that
the solution must support
Acceptance Criteria:
As a: new Mobile Payment System Wallet user • Existing users cannot re-register and will receive
an error message on attempt
I want: to register for a new Self Serve Account • All mandatory fields must be entered to
successfully register
So that: I can make use of the service • On successful registration, a new account is
assigned and registration email is sent
Given When Then
A New self serve account is created
AND a new account is provisioned within the mobile payment
system
The registration page is correctly
AND a User ID is associated with mobile payment system and
populated with mandatory fields
User does not exist in the system User's Mobile Carrier
AND the registrant clicks on
AND a User is assigned a new User ID
"register"
AND a User ID is unique to the User's Mobile Carrier
AND a User is set eligible for mobile payment system register &
get promotion
AND a User receives a registration e-mail containing...
Self Serve Account already exists The registration page is correctly The User is directed to an error page with the message "You
for the user populated with mandatory fields already have a Self Serve Account…"
AND the registrant clicks on AND the User data is purged from the registration queue
"register"

User is new The registration page is correctly The registration page is reloaded with missing or incorrect
AND Self serve registration page populated with mandatory fields information flagged for User update along with a message…
is loaded into the browser AND the registrant clicks on
"register"

12
Key Takeaways?
Writing User Stories is one of the core competencies of an Agile Team; but remember:

There are principles to gauge story

Writing stories is part art, part science quality but there are few rules to
follow when writing stories

It takes practice to get good at writing Expect the first stories you write to
stories be poor and for quality to improve
with practice

It takes even more practice to get stories Scrum Teams always struggle
right-sized getting stories that are small
enough for an iteration

Technical constraints need to be balanced It is important to probe the

against the technical solution feasibility of a story without
predetermining the solution

13
Breakout Activity: Story Writing
Objective: create stories at different levels of detail

Activity: Take requirements from your existing engagement, and tried to build 1-2:

• Business Epics
• Architecture Epics
• User activities
• User stories/system stories

Make sure to think about / include:

• INVEST Principles for your stories
• Include acceptance criteria
• Who benefits from the story, and what the benefit of the story is (As a, I want to, so that)

14
Story Mapping – a
hierarchical, visual backlog
Story Mapping allows teams to systematically decompose a project into
smaller units of business value using a structured approach

What is Story Mapping?

• A lightweight and collaborative approach to describing a product
• An arrangement of stories in a two dimensional map resulting in a sequential
narrative from left to right and a prioritization from top to bottom
• A highly visible representation of end-to-end product scope
• A site for conversation that is accessible and useful for setting context
• A practice that supports iterative delivery and product decomposition into MMFs

16
The anatomy of a Story Map is composed of four layers:
personas, epics, activities and stories
Fulfillment Fulfillment Network
1 Persona Customer Sales Rep Sales Rep
Vendor Clerk Operator
Billing Clerk

Time
Manage
Manage
2 Epic Manage Orders Manage Fulfillment
Provisioning
Activation and
Billing

Process Fulfillment Submit to Fulfillment Track Shipping

3 Activity Enter Order Process Order
Order Vendor Progress … …

4 Enter Order
Info
Submit
Order
Receive
Order
Submit
Fulfillment
Receive
Fulfillment
Save
Fulfillment
Transform to
Vendor
Submit
Fulfillment to
Receive
Shipping
Submit
Provision
. .
Order Order Order Fulfillment Vendor Notification Request
. .
Submit Process
Notify
Process
Fulfillment Update Update Notify
. .
View Order Order with Order
Customer Order Order Info Order Info Customer
Accessory Exceptions
Exception

Submit
Submit Process
Save Order Fulfillment to
Order with Shipping
Info Network
Features Exceptions
Optional

Managmt
Story
Resend
Update
Fulfillment to
Order Info
Vendor

1
User Personas - major categories of users that gain value from using
Add
Accessory the system.
2
Business/User epics - major objectives that that the system must
Add
Optional support, with tangible business outcomes and real business value.
Mobile
Features User activities-are tangible, sequential events that describe what the
3
user needs to do in order to get value.
Sequential
4 Stories - small, concrete units of business value that are also the
smallest increment of delivery, typically taking several business days to
17 deliver
The layout of activities provides a walkthrough narrative of the Story Map
How to Read a Story Map
Personas, Epics, and user • Cover scope by going vertically across the map
stories • Discuss at different levels of detail by going vertically
• Follow mandatory stories horizontally along the map
User stories • Follow optional stories vertically

Customer Sales Rep

Customers and sales Manage Orders

representatives enter orders Once the order is submitted
by entering order info and Enter Order Process Order
the system processes the order
submitting the order. by receiving the order and
Enter Order Submit Receive
Submit
Fulfillment
submitting a fulfillment order.
Info Order Order
Order
Optionally:
 During order entry time View Order
Submit
Order with
Process
Order
Notify Optionally:
 During receiving an order
Customer

the order can be viewed,

Accessory Exceptions

saved, updated or Save Order

Submit an exception may occur
and the system will
Order with
Info
modified with accessories Features

and optional mobile Update

process the order
features
Order Info
exception
 Submitted orders may  After submitting the
fulfillment order the
Add

have accessories or Accessory

optional mobile features Add

system may notify the
customer
Optional
Mobile
Features

18
Stories are visually prioritized by shuffling them vertically,
which forms a prioritized queue organized by activity
Time

 stories are reshuffled Manage Orders Manage Fulfillment …

and stacked
vertically according Enter Order Process Order
Process Fulfillment
Order
Submit to Fulfillment
Vendor
Track Shipping
Progress …
to priority.
.
Submit Receive Save Transform to Submit Receive Submit
Enter Order Submit Receive
Fulfillment Fulfillment Fulfillment Vendor Fulfillment to Shipping Provision

 Stories that are

Info Order Order
Order Order Order Fulfillment Vendor Notification Request

Shuffle Shuffle
.
required to create View Order
Submit
Order with
Process
Order
Notify
Customer
Process
Fulfillment Update
Order Info
Update
Order Info
Notify
Customer
.
the first MMF are
Order
Accessory Exceptions
Exception

placed at the top of Save Order

Info
Submit
Order with
Submit
Fulfillment to
Network
Process
Shipping

the stack
Features Exceptions
Managmt
Priority

Resend
Update
Fulfillment to
Order Info
Vendor

 stories that may be Shuffle

delivered later (and Add

Accessory

sometimes never) Add

are placed lower

Optional
Mobile
Features

down.

19
Breakout Activity: Story Mapping
Objective: To learn how to build a Story Map

Activity: You are Grainger Application Co., building mobile application solutions to
assist professionals excel in their trade. Your latest project is to deliver the HandyMan
App:

For people on the road

who need to find a hardware store
the HandyMan App
is a mobile application
that assists tradesmen and the DIY handyman with locating nearby hardware stores
Unlike other handyman applications
our product will enable store search by product

To keep in mind:
• Unknowns and assumptions
• Prioritization of epics/stories

20
 Prioritizing Work

21
Prioritizing User Stories
Prioritizing user stories is the primary responsibility of the Product Owner. Others can
provide guidance and support but the decision rests with the Product Owner. The
following factors should be considered when prioritizing user stories:

Factors:
• The business value of having the story
• The cost of developing the story
• The amount of knowledge and understanding of the system and future
requirements that will be gained from implementing the story
• Dependencies
• The amount of risk removed by implementing the story

22
Agile is all about breaking big projects into smaller units of work that can
deliver business value
 Big projects and big
releases are hard!
 Lots of variability and
Project unknowns!
 Lots of dependencies!

Minimum
Business
Marketable
Project Valued
Features
Features
(MMF)

23
Ideas are broken into MMFs and are further decomposed into
stories to be delivered independently
Overview

Minimum: The smallest set of functionality

Marketable: Provides significant value to the customer (e.g. ↑ Revenue, ↓ Cost, etc.)
Feature: Demonstrable behaviour of the product / solution

Delivery
Idea Discovery Story
Development Testing E2E Int. Test Deployment
Elaboration
1-2 Weeks Iterations 2-4 Weeks Iterations 2-3 Iterations

1 MMF1 MMF1

MMF2 MMF2
3
MMF3 MMF3 MMF3
2 WAIT

Duration
Story 1 – 3 Months S1 S1
Elaboration

S2 S2 S2 S2

Duration
1 – 10 Days

Work scatters and reforms as follows:

1. Ideas are broken into independent packages with market value
2. At the end of planning and prioritization, individual stories move into analysis one at a time
3. Work cannot be promoted into E2E testing until all stories are completedit was true to
itselfextruder what it is is like is everything it had everything in it that made mad Max
good
24
A Story Map can be leveraged to organize the project into
releases or MMFs by horizontally partitioning the stories
Once overall prioritization of stories necessary to Time
support each user activity is understood, the
entire Story Map can be divided into planned Manage Orders Manage Fulfillment
releases/MMFs. Horizontal lanes can be used to …
divide different MMFs from each other. The Story
Map can then be used to tell a narrative for a Process Fulfillment Submit to Fulfillment Track Shipping
Enter Order Process Order
particular MMF. This is done by traversing the Order Vendor Progress …
map from left to right and only looking at the
stories within a particular lane.

MMF 1: Basic order entry integrated to the Enter Order Submit Receive
Submit
Fulfillment
Receive
Fulfillment
Save
Fulfillment
Transform to
Vendor
Submit
Fulfillment to
Receive
Shipping
Submit
Provision
.
fulfillment vendor with manual provisioning and
.
Info Order Order
Order Order Order Fulfillment Vendor Notification Request
exception handling
.
MMF 2: Order entry with management features Save Order
Process
Notify
Process
Fulfillment Update Update Notify
Order
supporting order tracking, automated customer Info
Exceptions
Customer Order Order Info Order Info Customer
Exception
notifications and robust exception handling
Submit
Process
Fulfillment to
View Order Shipping
Network
Exceptions
Managmt
Priority

Resend
Update
Fulfillment to
Order Info
Vendor

MMF 3: Provide optional mobile features (Visual Add

Submit
Voice Mail, Premium SMS, Wi-Fi to Wireless) to Optional
Mobile
Order with
Features
customers Features

MMF 4: Provide accessories and full product Submit

catalogue to customers for ordering Add
Accessory
Order with
Accessory

25
MMFs should be defined with the goal of realizing business benefits and/or
validating key risks and assumptions
Business Value
Provide Mobile Service To
Telephone and Cable Overall Business Goal Business Risk
Customers
Technical Risk

MMF1 MMF2 MMF3

Internal Employee Trial 1 Internal Employee Trial 2 Full Customer Rollout

 100 employees  All employees in Major City  High and order entry UI
 Activate inside WAN  Partial automation of provisioning  3 million customers
 Manual processes  Activate over 3G network  Fully automated
 No support tooling  Support through DB views  Robust support tooling

Business Value: Business Value: Business Value:

N/A Build eager adopter community to promote Increase revenue stream through new
product service

Business Risk: Business Risk: Business Risk:

Demonstrate capability to build a viable Prove base product and partner integration N/A
solution before expanding into paying customers

Technical Risk: Technical Risk: Technical Risk:

Provisioning and activation of unproven Scaling the solution to meet higher volumes N/A
network elements and supporting the users

26
Think of Epics as User Stories but on an ‘epic’ scale

User Story: Can be decomposed into tasks; fits within an iteration

Epics: Can be decomposed into User Stories; too big to fit within an iteration

MMFs: Can be decomposed into Epics; may take multiple releases to complete

To get a sense of the relative scale:

Iteration1 Iteration 2 Iteration n Iteration n+1

Release 1
Breakout Activity: story prioritization
Objective: Understand how to prioritize using a story

Activity: Take the previously built story and group them into different MMFS of various
priority:

• Move stories vertically to indicate priority

• Group them into MMFS according to logical groupings
• Defining some MMFs using an “top-down” approach
• Some MMFs empty, and “estimate” how many stories could fit in them

28
 “Build solutions the business
“Build things with limited value” “We are slow” “Low collaboration / trust”
doesn’t want”
Story Exploration “Build solutions in an
unsustainable way”
“No predictability”
“We have low moral / people are
frustrated”
“Data / metrics don’t change
“No visibility into work” “We don’t adapt to change”
behavior”
Primary focus though not
Fit for purpose
2 complete story (Gaps)
Fulfillment Fulfillment Significant impact
Layout Customer Sales Rep Sales Rep Incremental improvement
Vendor Clerk (order of magnitude)
Story
Map Time 1

• Persona
Gain shared project Questions / Risks / Unknowns Analysis / Validation Activities

• Epic
Manage Orders Manage Fulfillment understanding,
• Activity … scope and extract Identify Questions/ Risks/ Unknowns:

• Key questions the team is responsible for

and needs to answer
Group Questions/Risks/Unknowns into
Analysis / Validation Activities that can be
completed with ~2 Weeks by the team

• Each analysis /validation activity should

be written as a hypothesis with a clear

• Story any risks /

• Risks based on assumptions or
challenges we need to address / validate
• Unknowns we need to resolve / analyze
objective and target end date
• Ex: Conduct Technical Fit/Gap workshop
with Technical Team XYZ to validate
proposed solution can meet Claims
Registration needs – Nov 23, 2012

Process Submit to Track assumptions using

Enter Order Enter Order Fulfillment Fulfillment Shipping Idea Canvas
…
Order Vendor Progress

.
Transfor Receive
Minimal Submit Receive Save Submit Submit
Marketable
Enter
Order
Submit Receive Fulfillm Fulfillm Fulfillm
m to
Vendor
Fulfillm
Shippin
g
Provisio .
Order Order ent ent ent ent to n
Feature 1 Info Fulfillm Notifica
Order Order Order
ent
Vendor
tion
Request .
10
Process
Save
Process
Notify
Fulfillm
Update Update Notify Repeat
3 Order ent
Order
Info
Excepti
Custom
er
Order
Order
Info
Order
Info
Custom
er
Cycle
ons Excepti
Prioritize on
stories Submit
Process
MMF 2 View 6 Explore Fulfillmen
t to
Shipping
Order Exception
stories Network
Mgmt
s 8 Build story 9 Release MMF
Story Sketch using story
Priority

Delivery
Update sketching Resend Idea Discovery
Story
Fulfillmen Development Testing Deployment
Order t to
Elaboration
Info Vendor
MMF 1 MMF 1

Add
Optiona
Submit
Order
7 Estimate MMF 2 MMF 2
MMF 3 l Mobile with stories using WAIT!
Feature Feature
Planning
s s
0 Poker
MMF 3 MMF 3 MMF 3

Submit 5
Add Order
MMF 4 Accesso with S1 S1
ry Accesso Narrate /
ry
4 Navigate
Story Map
Define S2 S2 S2
MMFs

29