User stories are a powerful technique agile teams used to communicate requirements. Yet all too often, the stories are poorly written or even incomprehensible. Some stories are too big and overlap across delivery cycles. Others are too small and don’t deliver sufficient details for developers. Join Paul Reed to learn the Seven Product Dimensions—the 7 D’s—which yield “just right” stories that users and product owners can write and developers can understand. Explore and experience the Seven Dimensions: user, interface, action, data, control, quality, and environment. Learn to identify options for high value business and user needs, and then assemble them into cohesive user stories. As you slice the options, you’ll see ways to leverage analysis models to quickly visualize and discuss options. Practice employing structured conversations about user stories to engage customers while taking business and technology perspectives into consideration. Find out how to establish acceptance criteria based on the value considerations to make your stories more valuable. Leave with a practical framework for writing “just right” stories.

1.
TH
Half‐day Tutorial
6/4/2013 8:30 AM
"The Flow of the
Agile Business Analyst"
Presented by:
Steve Adolph
WSA Consulting, Inc.
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

2. Steve Adolph
WSA Consulting, Inc.
An agile coach with WSA Consulting, Inc., Steve Adolph partners with Scaled Agile and Rally
Software where he pursues his passion for helping organizations get the job done. He has been
creating and managing software development projects long enough to remember Fortran and
OS/MVT JCL. Steve’s professional career includes many exciting and critical projects—
designing call processing software for digital telephone exchanges, design and development of
leading edge network management systems, railway signaling, and telecom billing. He has
diverse experience in job roles ranging from developer to chief engineer to CTO. Steve is
coauthor of the popular book, Patterns for Effective Use Cases.

3. The Flow of the
Agile Business
Analyst
Steve Adolph
Photo by K. W. Sanders
Intros
Form into a group at your table of 4 to 7 people and
interview each other…
What is their job role?
What is their agile experience (1‐5)?
What do they like to do outside of work?
What is one question they want answered during
this workshop? Record this on a post‐it note.
5. As a group, summarize your findings.
5 As a group summarize your findings
1.
2.
3.
4.
Be prepared to present your findings.

4. Steve Adolph
steve@wsaconsulting.com
4

5. In the agile
world, do I still
have a useful
job?
Where in an agile
g
process is the BA?
What does the BA do in
an agile process?
Photo by Caroline Schiff Photography

6. Agility and
g y
Agile
Economics
Photo by Warriorwriter
Agility
Photo by Kevin Eddy

7. Manifesto for Agile Software Development
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.
9
Much More than an Umbrella
Photo by Adry

8. “Big Tent” Agile
Photo by Brian Gurrola
Agile Economics:
Flow versus Batch
Photo by Tom Wahlin.
Photo by K. W. Sande

9. Batch
$
$
$
$
Analysis
Design
Budget
Implement
Test
Analyst
Team
Batch
Analysis
$
$
$
Design
Budget
Implement
Test
Analyst
Team

10. Batch
Analysis
$
$
Design
Budget
Implement
Test
Analyst
Team
Batch
Analysis
$
Design
Budget
Implement
Test
Analyst
Team

11. Batch
Analysis
Design
Budget
Implement
Test
Analyst
Team
Batch
Maximum WIP
No Finish Product
Analysis
Design
Budget
Implement
Test

12. Flow
Vision
$
$
$
$
Light Weight
Development Process
Budget
Team
Product Owner
Backlog of Items
19
Flow
Vision
$
$
$
Light Weight
Development Process
Budget
Product Owner
Backlog of Items
20
Team
F
e
a
t
u
r
e
Potentially Shippable
Product Increment

13. Flow
Vision
$
$
Light Weight
Development Process
Budget
Product Owner
Backlog of Items
Team
F
e
a
t
u
r
e
F
e
a
t
u
r
e
Potentially Shippable
Product Increment
21
Flow
Vision
$
Light Weight
Development Process
Budget
Product Owner
Backlog of Items
22
Team
F
e
a
t
u
r
e
F
e
a
t
u
r
e
F
e
a
t
u
r
e
Potentially Shippable
Product Increment

14. Flow
Vision
Light Weight
Development Process
Budget
Product Owner
Backlog of Items
Team
F
e
a
t
u
r
e
F
e
a
t
u
r
e
F
e
a
t
u
r
e
F
e
a
t
u
r
e
Potentially Shippable
Product Increment
23
Flow
Vision
Minimal WIP
Max Finished
Product
Budget
Product Owner
Light Weight
Development Process
Backlog of Items
Team
F F
e e
Min a
a
t t
u u
r r
e e
F
e
a
t
u
r
e
F
e
a
t
u
r
e
Potentially Shippable
Product Increment

15. Large Versus Small Batch
“Most fail to recognize both the critical relation
between batch size and cycle time, and the
critical relationship between batch size and
feedback speed”
p
Don Reinertsen, The Principles of Product
Development Flow
The Problem with Stage Gates
and Phases
Analysis
Design
The work product being
transferred from one phase to
another is 100% of the work
product of the previous phase
phase.
This is maximum theoretical batch
size and will result in maximum
theoretical cycle time …
Don Reinertsen, The Principles of Product Development Flow
Implement
Test

16. When it comes to flow…
How can we reduce software
development b t h size?
d
l
t batch i ?
What role (if any) does the
Business Analyst play?
Does Agility
g y
Obsolete
the BA
Role?

17. Scrum
Framework
Daily
Scrum
Sprint
2-4
Weeks
Product
Sprint
Backlog Backlog
Scrum Roles
Product
Increment
Scrum Master
Product Owner
Photo by Gavin White
Photo by Greg Peverill-Cont
?
Delivery Team
Photo by Reinhold Behringer

18. One
perception
of the BA
Worse
I like
purple.
It should be
red or
g
green.
I want a
range of color
options including
green, blue , and
purple
It shall be
green.

19. “The hardest part
of building any
software software
system is
system is
determining
precisely what to
build” – Frederick
Brooks
Photo by Lildude
What the BA Brings
Areas of Knowledge
Enterprise Analysis
p
y
Requirements Planning and
Management
Requirements Elicitation
Requirements Analysis and
Documentation
Requirements Communication
Solution Assessment and Validation
Skills
Communications
Facilitation
Domain Knowledge
Analysis
Photo by Gioia De Antoniis

20. Discussion Questions
In your groups discuss the following questions:
“Has agility and the economics of flow rendered the
role of the BA obsolete? Why?”
“Do agility and the economics of flow change the way a
BA works?”
As a group, summarize and be prepared to present
your findings.
The Shocking
g
Truth About
Requirements

21. They Change!
Uncertainty in the Project Goal
What our
SRS spec’d
Uncertainty in
Stakeholder
Satisfaction Space
Initial State
Courtesy Philippe Kruchten
Source: W. Royce, IBM
Actual Path and
precision of artifacts

22. The Fog
Analysis
Design
Implement
Test

23. Requirements and the Cone of
Uncertainty
The distribution of features used
in a typical application
How can we get
more of this….
…and less of this?

24. Reducing Waste
Leave things
until the last
RESPONSIBLE
moment
Photo by Nick Wheeler
Reducing Waste:
Reverse the Cone of
Uncertainty
What we need soon
What we need now
“Cone of Certainty”
Wishful Thinking
What we want
someday

25. How to Walk Down the
Road in the Fog
Release 1
ITERATION 1
Task 1
4 hours
Vision
Release 2
ITERATION 2
ITERATION 3
Task 2
6 hours
Release 3
ITERATION 4
Task 3
2 hours
Task 4
8 hours
Task 5
2 hours
Photo by Matthias Werner
Requirements Flow
Far out on the
Roadmap
Next Release
Current Release
Daily
Scrum
Sprint
2-4 Weeks

26. What’s in Your
Backlog?
A Backlog
Photo by Tony Case

27. User Stories:
The Early Days
Photo by Patti Gravel
USER STORIES*
Captures something valuable
Fits into one sprint
Fits into one sprint
(Could) fit on a 3x5 note card
Annotate with notes, and estimates
Details come from conversations with
Product Owner
Product Owner
Acceptance tests confirm story was coded
correctly
Photo by Improve it
* Original definition of a user story

28. As a <who>,
I want to <what>,
so that <why>.
As a traveler,
I want to be able to cancel a
reservation in one move, so
that all the details can
handled.

29. CARD
CONVERSATION
CO
CONFIRMATION
O
CARD
CONVERSATION
CO
CONFIRMATION
O

30. CARD
CONVERSATION
CO
CONFIRMATION
O

32. CARD
CONVERSATION
CO
CONFIRMATION
O
As a traveler, I want to be able to cancel a
reservation in one move, so that all the details can
handled.
handled
Acceptance Criteria:
Cancel res for hotel, car, plane,
train
Charge 10% fee
Confirmation email

33. Are User Stories Simply
Degenerate Use Cases?
Upgrade
Seat
"A use case is to a
user story like a gazebo
is to a gazelle"
is to a gazelle"
- Alistair Cockburn

34. User Stories:
The Modern Era
Photo by Brad Smith
What if the story doesn’t fit
into the sprint?
Product Backlog
Book Travel
Set Travel
Policy
Generate Backlog
Sprint
Expense
Report
Sprint Backlog

35. …Or what if you are building
this?
Product Backlog
Epics
Book Travel
Set Travel
Policy
Backlog Item
Generate
Expense
Report
UML Model
Courtesy Dean
Leffingwell
Epic
Realized by
0,1
1..*
Story

36. Epics and Stories
Photo by Toby Simkin
Story Splitting

37. A Value Based
Work Break Down
Story 1
Story 2
GUI
Business Logic
Database
Are We Done Yet?
Story 1
Story 2
GUI
Business Logic
Database

38. Are We Done Yet?
Story 1
Story 2
GUI
Business Logic
Database
The Agile BA
Five Principles
Creating a Flow of
Value

39. Principles for Creating a Steady
Flow of Sprintable Stories
Far out on
the
Roadmap
Next
N t
Release
Current
Release
Five Principles For the Agile BA
1. Open the Channels
2. Chart the Flow
3. Generate Flow
4. Lean out the Flow
5. Bridge the Flow
Photo by Gioia De Antoni

40. Principle #1
Open the Channels
Photo by Peter Vajda
Don’t be this…

41. …be this
Reconciling
Perspectives

42. Perspective Mismatch
“it’s getting everybody to understand things in a
similar manner. Get everybody on the same
page.
page I think that s – that’s the biggest
that’s that s
impediment is people walk away with
misunderstandings and you haven’t clarified. And
they just run with their assumptions or what the
way they understand things. And then we either
have to go and correct them or back out of it or
redo um something. And I think that’s the thing
that causes us the most pain I spend the most
pain.
time on in terms of preventing and mitigating” –
Site 1 Subject 1 follow-up
Is More Communications Always
Better?
Relationship Between Performance and Communications Frequency (Patrashkova-Volzdoska, et al., 2003, p. 266) ©
2003 IEEE
8
0

43. The BA as a
Boundary
Spanner
Photo by Robert Conley
Personal
Networks
Photo by Tim Dorr
8
2

44. Informal Backchannels
Photo by Mind the Goat
Cadence:
Regular
Backlog
Backlog
Grooming
Photo by Ross
8
4

45. Opening the Channels
In your groups discuss the following questions:
1. What are the channels both formal and informal that
are available to you for engaging both business and
engineering stake holders?
2. What organizational enablers exist that help keep
those channels open?
3. What organizational barriers (if any ) are there to
keeping those channels open?
4. What changes do you or your group have sufficient
influence to make that could open new channels or
would improve the flow of existing channels?
Summarize your findings and be prepared to report your
answers as a group.
Principle #2
Chart the Flow
Photo by Chris Seward

46. Multi Level Planning
Vision
Release 1
ITERATION 1
Task 1
4 hours
Release 2
ITERATION 2
ITERATION 3
Task 2
6 hours
Release 3
ITERATION 4
Task 3
2 hours
Task 4
8 hours
Photo by Matthias Werner
Vision – A Star to Steer By
True North*: Why are we building this?
Broad statement of project’s value
Create Alignment
Reasonably stable over 6 months to a year
*Dennis Pascal: Getting the Right Things Done
Photo by Charles Dawley
Task 5
2 hours

47. “For (customer), who (statement of need),
the (product name) is a
(product category) that
(key benefit, compelling reason to buy). Unlike
(primary competitor), our product
( i
tit )
d t
(statement of primary differentiation).”
Photo by Alexandar Boden
The Elevator
Statement
A Vision Tool:
The Product Box
Design box for the software
Name, Logo, Description, Key
Selling point on front
3-6 points to key differentiators
or compelling reasons to buy on
the back

48. The Roadmap
Define Dates and Milestones
Define Dates and Milestones
Set High Level Themes
Product Evolution over time
Photo by Michael_P
9
1
A Release
Release date
Driven by events
Defined release train schedule
Release Name and Objective
Internal delivery to a platform, other
team, or release train
Distribution to Production
Theme
Compelling reason to buy
New and primary product
differentiation
Significant business value to the
organization
Planned feature set
High-level descriptions of system
services that deliver value to the
user/customer
8/31/10
8/31/10
Release 1
Proof
Th
P
Theme: Prove “?”
For X, this Proof release
provides <what value>
Key Features:
1. Feature A
1
2. Feature B
3. Feature C

49. A Roadmap of Releases
Vision
8/31/11
8/31/11
10/30/11
10/30/11
1/?/12
1/?/12
3/?/12
3/?/12
R l
Release 1
Proof
Release 2
R l
Alpha
R l
Release 3
Beta
Release 4
R l
GA 1.0
Theme: Prove “?”
For X, this Proof release
provides <what value>
Key Features:
1. Feature A
2. Feature B
3. Feature C
Theme: Trial with critical
existing customers
For <who>, this Alpha
release provides <what
value>
Key Features:
4. Feature B’
5. Feature C’
6. Feature D
Principle #3
Generate Flow
Photo by Eric Begin
Theme: Upgrade Alpha
and expand to new
customers
For <who>, this Beta
release provides <what
value>
Key Features:
7. Feature B’’
8. Feature D’
9. Feature E
Theme: General
Availability
For <who>, this GA release
provides <what value>
Key Features:
10. Feature F
11. Feature G

50. UML Model of a Backlog Item
Model
optionally
elaborated
by
Backlog Item
Other Types
...
State
Diagram
Class
Diagram
Use Case
Epic
Realized by
0,1
1..*
Ref Dean Leffingwell
Story

51. Models and Model Usage
What models are you using?
Take 5 minutes to interview someone not seated in
your group:
1. What models do they use?
2. What aspects of the problem domain do the
models reveal?
3. Do they find the models useful?
4. What problems (if any) have they encountered
with the models?
Be prepared to present your findings
Photo by Jason Coleman
Model Driven User Stories
Upgrade Seat
Actor: Traveler: Ticketed passenger
Main Success Scenario
1. Traveler enters her account code for the flight and requests a
seat upgrade.
2.The system verifies the traveler is eligible for upgrade.
3. The system verifies there are seats available for upgrading.
As a traveler….
As a traveler I
Upgrade
want to upgrade
my seat… S t
t Seat
Traveler
4. The system upgrades the Traveler seat assignment, and the
appropriate upgrade certificates are removed from the Traveler’s
account.
5. The system issues an upgrade receipt to the Traveler.
Alternatives
1a: Traveler is a frequent flier
1a.1 The system displays her current mileage and recent flight
activity.
As a traveler I
want to see my
current status
3a: Traveler d
3 T
l does not h
t have enough upgrade certificates
h
d
tifi t
3a.1 Traveler purchases additional upgrade certificates.
Business Rules
Upgrade Eligibility
Platinum frequent flyers may request an upgrade 72 hours prior to
departure.
Gold frequent flyers may request an upgrade 24 hours prior to
departure.
Silver frequent flyers are not eligible for upgrades
As a traveler I want
to purchase
upgrade
certificates.

52. Split Along Acceptance Criteria
As a traveler, I want to be able to cancel a
reservation i one move, so th t all the
ti in
that ll th
details can handled.
Acceptance Criteria:
Cancel res for hotel, car, plane
Charge 10% fee
Confirmation email
Cancel res for hotel, car, plane
As a traveler, I want to be able to cancel my
reservations f a hotel, car, and plane i one
ti
for h t l
d l
in
move so all details are handled.
Acceptance Criteria:
plane reservation is canceled
Hotel reservation is canceled
Car reservation is canceled

53. Plane Reservation is Cancelled
As a traveler, I want to be able to cancel my
traveler
plane reservation in one move so all details
are handled.
Acceptance Criteria:
Cancelation request is sent to airline
Confirmation received from airline
reservation is canceled
Low‐Fidelity/High Fidelity
Photo by Vanessa Arn
Photo by Alberto Cardona

54. Bill Wake’s 20 Ways to Split a Story:
1 through 9 the “Big Picture”
Consider First
Defer / Later
Explanation
Research
Implement
What have others done?
Spike
k
Implement
l
Explore a quick solution
l
k l
Manual
Automated
Often have to retain manual solution anyway
Buy
Build
Trade cost of customizing….
Build
Buy
….versus cost of implementing yourself
Single User
Multi – User
Fewer worries about scale, user accounts.
API only
User Interface
Test may function without UI
Character or Script GUI
UI
Simple interface can prove out ideas
Generic UI
Naked objects approach can be cheaper
Custom UI
- http://xp123.com/articles/twenty-ways-to-split-stories/
Bill Wake’s 20 Ways to Split a Story:
10 through 16 the “ilities”
Consider First
Defer / Later
Explanation
Static
Dynamic
Do once and ignore updates
Ignore Errors
Handle Errors
dl
Minimize Error codes (don’t ignore exceptions)
d d
Transient
Persistent
Focus on behaviour over persistence
Low Fidelity
High Fidelity
Quality of result (e.g. pixel depth)
Unreliable
Reliable
“Perfect uptime is very expensive” Wm Pietri
Small Scale
Large Scale
Build load capacity over time
Less “ilities”
More “ilities”
Address NFRs later
- http://xp123.com/articles/twenty-ways-to-split-stories/

55. Bill Wake’s 20 Ways to Split a Story:
17 through 20 the “Features” (+ 2 more)
Consider First
Defer / Later
Explanation
Few
Many
Easier to do fewer features
Main Flow
l
Alternative
l
Flows
h
ll
bl
h
Happy paths versus all possible paths
0
1
Nothing is easier than something
1
Many
One is easier than many
One level
All levels
One level is the base case for all levels
Base Case
General Case
Base case must be done, others needn’t
- http://xp123.com/articles/twenty-ways-to-split-stories/
Creating a Cadence for
Generating Flow
Visioning
Road mapping
Release planning
Sprint Planning
Backlog Grooming
B kl G
i
Photo by Davide Simonell

56. How are you generating flow?
In your groups discuss the following topics
1.
1 What ceremonies do you have that generate flow?
2. What are the impediments to generating a flow of
sprintable stories?
3. What changes do you have influence to make that can
overcome these impediments and improve flow?
Be prepared to share your conclusions
conclusions.
Principle 4
“Lean out the Flow”
Craig Kohtz

57. Wow! I love what I’m
hearing about this agile
transformation thing you’re
doing…are you really
delivering new features
every two weeks?
Yes! We get new
valuable features into
revenue service every
two weeks.
Photo by World Bank Photo Collection
Photo by Pennybinary
I love you guys! Look I’ve
been thinking about a
new feature that will just
rock the market place.
When can I have it?
Let’s see, you’ll have to
talk to the product owner,
but right now we have
over 300 items in our
backlog and we’re
delivering about 5 items
each sprint…..
Photo by World Bank Photo Collection
Photo by Pennybinary

58. I’m not sure I
like this agile
thing
anymore
So backlog item
number 243…
Photo by Nearsoft
Problems with
Queues
Queues
Create…
Longer Cycle
Times
Increase Risk
More Variability
More Overhead
Lower Quality
From Product Development Flow by Donald
Reinersten
Less Motivation

59. Agility, Queues and Little’s Law
Wq - queue time for average jjob
q
g
Wq =
Lq
Lq - queue length
λ
λ
average processing
rate
Reducing Queue
Time: Increase λ
I can take a
story
We’re really
getting
swamped here.
Yeah so can
Y h
I
The self organizing
team.
Photo from Nearsoft
Me too…

60. Reducing Queue Time:
Limit Queue Length (Lq)
We have over 300 10
items in our backlog
and we’re delivering
about 5 items each
sprint…..
Photo by Pennybinary
Decreasing Lq Queue Length:
Shape of a well groomed Backlog

61. Reducing Queue Time
Reduces Waste
Leave things
until the last
RESPONSIBLE
moment
Photo by Nick Wheeler
Using Multi‐Level Planning
to limit Queue Length
Release 1
ITERATION 1
ITERATION 2
Release 2
ITERATION 3
ITERATION 4
Vision
Release 3
ITERATION 5
ITERATION 6

62. Decreasing Lq Queue Length:
Multi Level Planning and the Groomed Backlog
Future Release
Next Release
Current Release
Reducing Queue Length:
Backlog Policy and Well Groomed Backlog(s)
Portfolio Backlog:
Epics representing large initiatives
Feature Backlog:
Features for
Next Release
Team Backlog:
Current Release

63. Visualizing Queues:
The Cumulative Flow Diagram
Departures
Arrivals
Time In Queue
Quantity In Queue
Cumulative
Quantity
Time

64. Toss the Trash
Photo by Ming Xia
Principle #5
Bridge the Flow
Photo by Ava Babil

65. Governance and the PMO View
of the World
Initiation /
Planning
Will it be ready in time?
Project
Execution
Will it work?
Is it safe? and
Control
Is this project still a
good bet?
Project
Conclusion
Governance Manifested as
Stage Gates…
Photo By Kaustav Bhattacharya
Version 7

66. Governance Manifested as
…or as Documentation Sets
Stage Gates
Photo by Daniel9d Martins
Why we have those
Governance Practices
You spent
HOW much
HOW
h
building
this?!
@%$# 327 million
g
gone just like
j
that…sigh. Better
make sure that
doesn’t happen
again

67. PMO and Development:
The Two Solitudes?
Initiation /
Planning
Project
Execution
and
Control
Project
Conclusion
Product
Increment
Bridging the Two Solitudes
…
Initiation / Planning
Project
Execution
and
Control
Project
Conclusion

68. Flow Enables Fast Feedback
Cycles. So…
…are those Stage Gates and
Documents Still Relevant?
Photo By Kaustav Bhattacharya
Photo by Daniel9d Martins
Version 7

69. Photo by Mroach
Optimize the
Stage Gate
Eliminate, Lighten, or
Optimize Documentation
Photo by Jules Holleboom

70. Cultivate Allies
Photo by Andy Doro
Reverse Engineer Governance
Work Products
Upgrade Seat
Actor: Traveler: Ticketed passenger
Main Success Scenario
1. Traveler enters her account code for the flight and requests a
seat upgrade.
2.The system verifies the traveler is eligible for upgrade.
3. The system verifies there are seats available for upgrading.
4. The system upgrades the Traveler seat assignment, and the
appropriate upgrade certificates are removed from the Traveler’s
account.
5. The system issues an upgrade receipt to the Traveler.
Alternatives
1a: Traveler is a frequent flier
1a.1 The system displays her current mileage and recent flight
activity.
activity
3a: Traveler does not have enough upgrade certificates
3a.1 Traveler purchases additional upgrade certificates.
Business Rules
Upgrade Eligibility
Platinum frequent flyers may request an upgrade 72 hours prior to
departure.
Gold frequent flyers may request an upgrade 24 hours prior to
departure.
Silver frequent flyers are not eligible for upgrades

71. Working in your groups, discuss the following
questions for Bridging the Flow:
In terms of stage gates and documentation and rapid
feedback
f db k cycles:
l
1. Which stage gates and documents are relevant
(e.g. actually used, or necessary)?
2. Which are required by outside regulatory agency?
3. Which could be eliminated altogether?
4. Which could potentially be, optimized, or
lightened?
li ht
d?
5. Which gate keepers can you engage as allies?
Be prepared to report out your answers (and questions)
The Flow of
the Agile BA

72. Where is the
BA?
Scrum Master
Product Owner
Photo by Gavin White
Photo by Greg Peverill-Cont
?
Delivery Team
Photo by Reinhold Behringer
Use “small
batches” to
deliver a steady
d li
t d
flow of value
Product
Increment

73. The 5 Principles for the Flow of the
Agile BA
Principle 1: Open the Channels
Cadence
Boundary Spanning
Personal Networks
Informal Backchannels
Principle 2: Chart the Flow
P i i l Ch t th Fl
Vision
Roadmap
The 5 Principles for the Flow of the
Agile BA
Principle 3: Generate Flow
Model Driven Stories
Splitting stories along acceptance criteria
Lo‐fidelity/Hi Fidelity story splits
Principle 4: Lean Out the Flow
Self organization – decreasing average processing time
Limit Queue Length
Multi‐level planning (Chart the Flow)
Monitor backlog size

74. The 5 Principles for the Flow of the
Agile BA
Principle 5: Bridge the Flow
Optimize Stage Gates
Eliminate, Lighten, or Optimize Documentation
Cultivate Allies
Don’t let required work products slow cycle time: Be
prepared to reverse engineer work products
Next Steps?
Photo by Fionnaigh McKenzie

75. Thank You!
Steve Adolph
steve@steveadolph.com