Agile Use Cases
( Writing Effective Use Cases
meets
Agile Software Development ! )
Alistair Cockburn
Humans and Technology
acockburn@aol.com
http://Alistair.Cockburn.us
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 1
Can use cases be agile?
(Can you be agile with use cases?)
Yes
Yes
Do use cases contradict Agile ?
: Use cases / not use cases / value of use cases vs stories
: Agile / not agile / value of agile
When should we use agile use cases ?
: document faster, later, cheaper,
: plan on changing your mind along the way,
: always.
Detecting and exercising available dimensions of freedom
: Write less, more clearly (tips).
: Shortcut process & use case structure ... (tips, tradeoffs)
: Tools
Q&A
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 2
Coming from agile non-use-cases to agile UCs
is easier than coming from non-agile UCs
Overly complex use case writing is hard to change,
tied to overly complex process (hard to change!)
Already understanding Agile means
: already have a lighter process
: already have mindset to simplify the writing
: --> leads to agile use case writing.
Need to understand
: (A) Simple use cases
: (B) Agility as energy savings
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 3
Part 1:
What is / isn’t
a
use case
(good for)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 4
Good use cases
are
aren’t
Text
No GUI
No data formats
3 - 9 steps in main scenario
Easy to read
At user’s goal level
Record of decisions made
UML use case diagrams
describing the GUI
describing data formats
multiple-page main scenario
complicated to read
at program-feature level
tutorial on the domain
Use cases *can be* written -all up front --or-- just-in-time
each to completion --or-- in (usable) increments
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 5
Robert Martin: “It shouldn’t take longer than 15 minutes to teach someone how to write a use case!”
Use case: Text describing scenarios of user
succeeding or failing to achieve goal.
(goal of primary actory)
“Place an order”
(level of goal [summary, user, subfunction])
(primary actor)
(User goal / Clerk)
(action steps:
full sentences showing
who takes the action!
3 - 9 steps long.)
Main scenario:
1. Clerk identifies customer, item and quantity.
2. System accepts and queues the order.
(condition causing different actions)
Extensions:
1a. Low credit & Customer is ‘Preferred’:
System gives them credit anyway.
(action step(s)
handling those conditions)
1b. Low credit & not ‘Preferred’ customer:
Clerk accepts only prepayment.
2a. Low on stock: Customer accepts rain-check:
Clerk reduces order to available stock level.
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 6
Good use cases
are
aren’t
Text
No GUI
No data formats
3 - 9 steps in main scenario
Easy to read
At user’s goal level
Record of decisions made
UML use case diagrams
describing the GUI
describing data formats
multiple-page main scenario
complicated to read
at program-feature level
tutorial on the domain
Use cases *can be* written -just-in-time
--or-- all up front
in (usable) increments --or-- each to completion
(more Agile)
Alistair Cockburn
(more common)
©Humans and Technology, Inc., 2000-2003
Slide 7
Use cases summarize end-user experience,
not programmers tasks.
1980’s: Let’s write requirements in features!
: User’s don’t understand...
...user pressure to write in use cases...
1990’s: Let’s write requirements in use cases!
: Programmers’ work units are features, not use cases...
...programmer pressure to write in features...
2000: So let’s write requirements in features!
: FDD & XP user stories...
...lose the end user experience again ...
A pendulum of features vs. use cases
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 8
Use cases have strong & weak points
(as anything)
1. Use cases hold functional requirements in an easy-toread text format
2. They make a good framework for
non-functional requirements & project scheduling.
3. Use cases show only the Functional req’ts.
4. Design is not done only in use case units.
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 9
Use cases do not collect formulae, state,
cardinality, performance, uptime, ...
Examples:
1. Order cost = order item costs * 1.06 tax
2. Promotions may not run longer than 6 months.
3. Customers only become Preferred after 1 year.
4. A customer has one and only one sales contact.
5. Response time is less than 2 seconds.
6. Uptime requirement is 99.8%.
7. Number of simultaneous users will be 200 max.
Capture those in any form available,
*somewhere* in your requirements files !
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 10
Goals make a good structure on which to hang
requirements & project details.
Project planning capitalizes on goal structure:
: Useable Releases.
: Priorities,
: Schedule, staffing
Name
Update customer
Scan products
Generate invoice
Funds transfer
P. Actor
Customer
Customer
Finance
Finance
Pr.
high
high
high
med
Diff.
med
high
high
high
Release
1
1
3
4
(Note: spreadsheets are perfect for this!)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 11
Use cases provide 4 values to the project at
different times:
1. The list of goal names provides executives:
: Shortest summary of what system will contribute
: Project planning skeleton (priorities & timing)
2. The main success scenario provides all:
: Agreement as to the system’s responsibilities
3. The extension conditions provide programmers:
: List of things programmers have to watch for
: List of things analysts have to investigate
4. The extension handling steps provide dev’t team:
: Record of (tricky) business policy decisions
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 12
The hard parts about use cases is not typing,
but thinking and agreeing.
• Total time
: ~ 3 days construction
: ~ 2 hours typing
: 2-3/4 days spent thinking, arguing (over policy).
1. Is each step correct?
2. Are there any system responsibilities between steps?
3. Are there any outside systems this system should use?
4. Are there any other stakeholders whose interests we
missed?
5. Did we catch every extension condition?
(The programmers will (maybe))
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 13
Don’t try to teach a tutorial on the subject
domain within the use cases!
In any text, receiver must always jump a gap.
: Experts jump larger gaps
: Novices jump smaller gaps.
To teach a domain, you need a textbook, not use cases.
: Textbooks use smaller gaps.
: Think of use cases as “documenting decisions”,
not “teaching the domain.”
Target the gap for the people: “sufficient”
communication with a “small-enough”gap.
: More experienced people need less writing !
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 14
Part 2:
What is / isn’t
agile
development
(good for)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 15
(3-1/2)
History: How did “agile” arise?
“Agile” techniques were in use since the beginning.
Agile (mobility-based) techniques did not show
competitive advantage in the 1970s / 1980s,
but did during the 1990s and do now.
1994: trials of semi-formal agile methodologies
RAD
DSDM
XP
Crystal
Scrum
Adaptive
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 16
(4-1/2)
Development approaches are only attitudes,
“centering of the attention”.
Declarations of core values declare an “attitude”
An attitude cannot promise success in the future,
it can only be spoken successfully in the past tense.
it is only a wish to be a certain way
A would-be agile process
A would-be predictable process
A would-be repeatable process
A would-be inexpensive process
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 17
2001 Agile Software Development Manifesto
- a declaration of values
“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.”
(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 Martin,
Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas )
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 18
Agile development works because
software development is an economic game
Economic consequences to each choice.
: Less is usually better... “sufficient” is enough.
(Project success factors reviewed:)
(Agility resides Here!)
Nourishment
Citizenship
Communication
Focus
Increments
(Includes developers AND users!)
Skills
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 19
The “iron triangle” isn’t a triangle at all -“Process” is the 4th dimension !
Agile = shortcutting the process (cheating legally to win)
Scope
Scope
Process
Time
Resources
Time
Resources
(Some people use agile to handle late-breaking requirements changes,
I use it to improve development efficiency)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 20
Agile development: short circuiting process
steps without compromising final product.
• Focus on *early* & *frequent* delivery of *useful*
software to real users using *just-in-time* techniques.
• Focus on *feedback* loops at all levels
: (requirements design code test communication . . . )
• Replace fanfare around the process with
people checking in with other people.
• *Talk* to users / sponsors, find out what they need!
• Adjust your working habits *monthly or quarterly* to
fit your particular situation!
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 21
The Agile attitude focuses on:
1. Talent & Skill (fewer better people)
2. Proximity (developers - developers - users)
3. Communication (morale, daily standup)
4. Just-in-time requirements and design
5. Frequent Delivery
(incremental development)
6. Reflection
7. Less paper, more tacit / verbal communication
8. Tools
9. Quality in work
10. Different strategies for different projects
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 22
Good agile development
is / does
isn’t / doesn’t
Efficient
Lots of “just in time”
Adjust to circumstances
(Re)Plan regularly
Lots of person-to-person comm.
Adaptively cut fat in the process
hacking
Giant Energy Up Front (GEUF)
only XP (XP is one alternate)
plan-less
People sitting in isolation
rigid adherence
Agility *can*
Be heavier or lighter, depending on circumstances
Use various requirements techniques
(e.g., use cases, stories, features)
In agile development we value
following the principles over following specific practices !
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 23
Is / Isn’t: Misconstruing the message
1. Agile SD is cheating
2. Agile SD requires the best developers
3. Agile SD is hacking
4. Agile SD won’t work for all projects
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 24
1. Agile techniques are “cheating”.
·
·
·
·
·
·
Hire good people;
Seat them close together to help each other out;
Get them close to the customers and users;
Arrange for rapid feedback on decisions;
Let them find fast ways to document their work;
Cut out the bureaucracy.
This is:
cheating
stacking the deck
a good idea
the heart of agile software development
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 25
2. Agile only works with the best developers.
Every project needs at least one experienced and
competent lead person. (Critical Success Factor)
Each experienced and competent person on the team
permits the presence of 4-5 “average” or learning
people.
With that skill mix, agile techniques have been shown to
work many times.
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 26
3. Agile is hacking.
(Hacker interpretations are inevitable.)
Hackers: “...spend all their time coding”
Agilists: ...test according to project priorities,
recheck results with users often.
Hackers: “...talk to each other when they are stuck”
Agilists: ...talk to each other and customers as
a matter of practice.
Hackers: “...avoid planning”
Agilists: ...plan regularly
Hackers: “...management caves in out of fear”
Agilists: ...expect management to provide priorities,
& participate jointly project adjustments.
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 27
(5-6/6)
4. Agile won’t work for all projects.
Right. (Business isn’t fair).
Agile is an attitude prioritizing:
Project evaluation based on delivered code
Rapid feedback
People as a value center
Creativity in overcoming obstacles
Not every team
... values the Agile value set.
... can set up the needed trust and communication
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 28
Lighter-agile vs. Heavier-agile :
Light is good, but has limits
# people needed
Heavy
methodology
more people
fewer people
Light methodology
Problem Size
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 29
(defects cause loss of...)
Criticality
Suit the process to the occasion
project size & priorities, system criticality
. . . Prioritized for Legal Liability
Prioritized for Productivity & Tolerance
Life
(L)
L6
L20
L40
L100
L200
L500
L1000
Essential
money
(E)
E6
E20
E40
E100
E200
E500
E1000
Discretionary
money
D6
(D)
D20
D40
D100
D200
D500
D1000
C20
C40
C100
C200
C500
C1000
Comfort
(C)
C6
1-6
Alistair Cockburn
- 20
- 40
- 100
- 200
- 500 - 1,000
Number of people involved +20%
©Humans and Technology, Inc., 2000-2003
Slide 30
Productivity:
(Flux & Uncertainty)
Reality Check: Work as parallel & light as
project features and personalites permit.
Project requires at least this much
productivity to succeed
old-school
projects
e-projects
Where is
your group,
your project
on this graph??
Group’s tolerance for ambiguity / uncertainty
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 31
Part 3:
Agile-ly generating
agile use cases
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 32
Core elements to using use cases *agile-ly*
increments,
just-in-time,
close communication
• Write just enough use case content to plan to the
needed planning horizon
: Long (project) horizon -> just use case names or briefs.
: Short (iteration) horizon -> extension handling.
• Just barely beat the programmers to the extension
handling decisions (just in time)
• Write just enough content for the team to understand.
• *Show* UCs, system to users/sponsors, get feedback!
• Adjust your working habits *each iteration* to fit your
particular situation!
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 33
Core elements to using use cases *agile-ly*:
increments, just-in-time, close communication
Ask,
• How much do we need to write at this time?
• When do we need to write more?
• What is the fastest way to write/convey them?
• Who benefits from more information or more detail?
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 34
Take advantage of available degrees of
freedom in the process
1. Write less more clearly (always)
2. Write less (sometimes)
3. Shortcut the use case structure (sometimes)
4. Write later & shortcut the process (usually)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 35
1. Write less more clearly (always)
Text
No GUI
No data formats
3 - 9 steps in main scenario
Easy to read
At user’s goal level
Record of decisions made
UML use case diagrams
describing the GUI
describing data formats
multiple-page main scenario
complicated to read
at program-feature level
tutorial on the domain
(shorter,
more economic
& more readable!)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 36
2. Write less (sometimes)
(the economics of communication)
• Fully dressed use cases
• Casual use cases
• Use case briefs
The correct form to use depends on your
project’s priorities and properties !
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 37
Economics of communication:
Fully Dressed (expensive, complete)
Use Case 12. Buy stocks over the web
Primary Actor: Purchaser (user)
Scope: PAF
Level: user goal
Precondition: User already has PAF open.
Guarantees: sufficient log information exists that PAF can detect what went wrong.
Success Guarantees: remote web site acknowledged purchase, user's portfolio updated.
Main success scenario:
1. User selects to buy stocks over the web.
2. PAF gets name of web site to use (E*Trade, Schwabb, etc.)
3. PAF opens web connection to the site, retaining control.
4. User browses and buys stock from the web site.
5. PAF intercepts responses from the web site, and updates the user's portfolio.
6. PAF shows the user the new portfolio standing.
Extensions:
2a. User wants a web site PAF does not support:
2a1. System gets new suggestion from user, with option to cancel use case.
3a. ...
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 38
Economics of communication:
Casual (less expensive, less complete)
Buy something
(Purchaser / user-goal level)
The Requestor initiates a request and sends it to her or his Approver,
who completes the request for submission and sends it to the Buyer.
The Buyer finds the best vendor, initiates PO with Vendor.
At any time prior to receiving goods, Requestor can change or
cancel the request. Canceling it removes it from any active processing.
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 39
Economics of communication:
Brief (inexpensive, just a short note)
Actor
Goal
Brief Description
...
...
...
Production
Staff
Prepare
digital
cartographic
source
Convert external digital data to
standard format, validate &
correct in preparation for merging
with operational database.
...
...
...
(Note: spreadsheets again!)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 40
3. Shortcut the use case structure (sometimes)
Use cases are not read by a compiler but by a human...
--> so,
Don’t be rule-bound, but adapt the form to your needs.
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 41
Test department needs detailed requirements.
Development can usually use agile ones.
[Alistair’s generic process model]
(Shorter, cheaper, easier to read, more stable (agile) use cases)
Usage
expert
(Development department)
R
Use
cases
Domain
expert
Data
formats
D
UI
descr.
R
D
R
D
Program
Tests
(Test department)
(Detailed, expensive, long, tedious, brittle use cases)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 42
4. Write later and shortcut the process
(usually)
Use cases *can be* written -just-in-time
--or-- all up front
in (usable) increments --or-- each to completion
(more common)
(more Agile)
Use the “Validation V” view of increments
Req'ts
Validate req'ts
Design
Code
Alistair Cockburn
Validate logic
Validate syntax
©Humans and Technology, Inc., 2000-2003
Slide 43
Project horizon -> all use case briefs or casual
Iteration horizon -> full use case, just-in-time
S
(all UCs, ultra-light content, estimation purposes)
Full Project
(just-in-time, complete) (just-in-time, complete) (just-in-time, complete)
Iteration
Iteration
Iteration
S (10 more use cases) S (10 more use cases)
(10 use cases)
E
Alistair Cockburn
E
E
E
©Humans and Technology, Inc., 2000-2003
E
E
Slide 44
Finally, Tools: Choose for the value it delivers,
not for its popularity
• List of UCs for project planning & status:
: Spreadsheets are very effective
: Lotus Notes medium effective
• Main success scenario for agreement:
: Flipcharts in meeting good for fast disagreement
: Word processor (Lotus Notes) quite effective
• List of extension conditions for completeness:
: Word processor quite effective
: Flipcharts in project room? (untried)
• Extension handling steps for policies:
: Word processor very effective
: WikiWiki technology? (http://c2.com)
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 45
Summary of Agile Use Cases
• User’s goal level - Text - 3-9-step main scenario No GUI - No data formats - Easy to read Record of decisions made (not a tutorial)
• Write briefs and casuals to estimate & plan project
Write full use cases just-in-time per iteration
• Just-in-time = extension-handling decisions made
before the programmer gets around to asking for
them.
• Spreadsheets good for briefs, planning activities.
Focus on communicating, not filling templates
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 46
(1) In 10 minutes: Write a use case for a clerk
entering a video rental into the computer.
(
Write the basic dialog between the clerk and the system,
Name all the things that could go wrong during the procedure. )
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 47
(2) In 10 minutes: Name all the use cases for a
video rental store computer system.
(
List every person who will use the computer system.
For each person, list every reason they have to use the system. )
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 48
(3) In 5 minutes: Prioritize the list of UCs
(order in which to develop & deliver them).
(
Rank for when it is *really* needed, by dependency or business payback. )
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 49
Agile
Use Cases
Alistair Cockburn
Humans and Technology
acockburn@aol.com
http://Alistair.Cockburn.us
Alistair Cockburn
©Humans and Technology, Inc., 2000-2003
Slide 50