Transcript Designing A Light Methodology

1
Making Agile Development
Crystal Clear
Alistair Cockburn
http://Alistair.Cockburn.us
Jeff Patton
http://www.JeffPatton.us
©A. Cockburn 2008
2
The Shape Of This Course
Monday: Foundations for the Crystal Agile Approach
o 9:00 – 10:30: People, Communication, and the Agile Software
Development Cooperative Game
o 11:00 – 12:30: Crystal Agile Process Construction
o 12:30 – 1:30: Lunch
o 1:30 – 3:00: Incremental Thinking Simulation
o 3:30 – 5:00: Communication in Time-Boxed Development
Tuesday: Applying Agile Thinking
o 9:00 – 10:00: Discovering Requirements Incremental in Agile Projects
o 10:30 – 12:00: Collaboratively Planning an Agile Development Cycle
o 12:00 – 1:00: Lunch
o 1:00 – 2:00: The Agile Product Owner Role
o 2:30 – 3:30: Applying Lean Thinking to Agile Development
o 3:30 – 5:00: Reflecting on Your Current Process
©A. Cockburn 2008
3
People learn skills in 3 stages
Shu
Learn a technique
follow
Ha
Collect techniques
break
Ri
Invent / blend techniques
leave
©A. Cockburn 2008
4
Crystal
is a family
of methodologies
based on a
genetic code
©A. Cockburn 2008
5
Crystal’s Genetic Code
Mindset
Samples
Design priorities
Key Techniques
Project properties Design principles
©A. Cockburn 2008
Mindset
6
Crystal’s Genetic Code
Mindset
Design priorities
Project properties
Samples
Key Techniques
Design principles
Software development consists only of
making ideas concrete in an economic context
... a Cooperative Game
of Invention and Communication
©A. Cockburn 2008
Mindset
7
... a goal-directed cooperative game
Infinite
Organization Survival
Career Management
Finite w/
no fixed end
Finite &
goal-directed
King-of-the-hill
wrestling
Poker
Tennis
Chess
Competitive
Jazz music
Rock-Climbing
Theater
Exploration
Journalism
Software
Development
Cooperative
©A. Cockburn 2008
Mindset
8
... with two conflicting subgoals:
Deliver this software
Set up for the next game
©A. Cockburn 2008
Mindset
9
The situations never repeat!
©A. Cockburn 2008
Mindset
10
Adjust to your situation
Project Classification Scale:
Criticality
Life
Essential
moneys
Discretionary
moneys
L6
L20
X
E6
X
D6
L100
E40
E100
X
E20
X
L40
X
D20
D40
D100
C20
C40
C100
Comfort
C6
1-6
- 20
- 40
- 100
Number of people coordinated
©A. Cockburn 2008
11
The Samurai Musashi (1645) describes programming
The field is rife with showmanship,
popularization and profiteering;
schools become theatrical, dressing
up, showing off to make a living.
Where you hold your sword depends
on your relationship to the opponent,
on the place, and must conform to
the situation;
One can win with the long sword,
and one can win with the short
sword. --- Whatever the weapon,
there is a time and situation in
which it is appropriate.
Wherever you hold it, the idea is to
hold it so that it will be easy to kill the
opponent. Whatever guard you
adopt, think of it as part of the act of
killing.
If your sword misses the opponent,
leave it there for the moment, until
the opponent strikes again,
whereupon strike from below.
The views of each school are
realized differently, according to the
individual person, depending on the
mentality. In my school, consideration
is given to any idea, however
unreasonable.The heart of the matter
is to use knowledge to gain victory
any way you can.
Observe reflectively, with overall
awareness of the large picture as
well as precise attention to small
details.
©A. Cockburn 2008
12
Peter Naur 1986: The result of programming is the
theory held by the programmers.
1. The programmer must build a theory of how certain affairs
of the world will be handled by a program -- Explain how
those affairs are mapped into it -Perceive the similarity of new demands to facilities built.
o This knowledge is the mental possession of a programmer,
transcending what is possible in documentation.
2. A program decays from modifications made by people
without the underlying theory.
o For a program to retain its quality it is mandatory that each
modification is firmly grounded in its theory.
©A. Cockburn 2008
13
Naur 1986: Case Study of a compiler extension
Group B modified Group A’s design.
Group B’s solutions were found to make no use of the facilities
that were inherent in the existing compiler and were
discussed at length in its documentation.
Group A was able to spot these instantly and could propose
simple, effective solutions, framed within the existing
structure.
The program text and additional documentation was
insufficient in conveying to even the highly motivated group
B the deeper insight into the design, the theory immediately
present to the members of group A.
©A. Cockburn 2008
Mindset
14
Peter Naur (1986)
Programming is Theory Building
©A. Cockburn 2008
Mindset
15
Peter Naur (1986)
Programming is Community theory building
?
©A. Cockburn 2008
Mindset
16
Peter Naur (1986)
Programming is community theory building
Communicate the theory to the next person!
?
©A. Cockburn 2008
Mindset
17
COMMUNICATION is
touching into shared experience
As you share more experiences, you can
write less ...
As you share fewer experiences, you must
write more !
©A. Cockburn 2008
Mindset
18
Communicate the theory of the design
the program “theory”
design
patterns
UML
source code
©A. Cockburn 2008
Mindset
19
Communication Effectiveness
Face-to-face is the most effective Try video !
2 people at
whiteboard
2 people
on phone
Videotape
(Courtesy of Thoughtworks, inc.)
2 people
on chat
Audiotape
Paper
Richness of communication channel
©A. Cockburn 2008
Mindset
20
Communicate Face-to-face
While Leveraging a Model
Zak describes the domain model and state changes as the
application us used
©A. Cockburn 2008
Mindset
21
Communicate Face-to-face
While Leveraging a Model
Michael describes how physical inventory cycle counting
©A. Cockburn 2008
Mindset
22
Distance is expensive
Kim
12 people:
= $100,000 / yr penalty
Pat
12 people
= $300,000 / yr penalty
Kim
Pat
People won’t climb stairs to ask questions
You can use this to create a Cone of Silence !
©A. Cockburn 2008
Mindset
23
Kim Pat
Kim Pat
Nearby programming
Programming in pairs
“Managing the Flow of Technology,” Thomas J. Allen,
M.I.T. Sloan School of Management
“Distance Matters,” Olson & Olson
©A. Cockburn 2008
Mindset
24
Communication flows in currents
Attend to morale !
Photo courtesy of Evant corp.
Reduce drafts !
©A. Cockburn 2008
Mindset
25
Balance osmotic communication against drafts
Meeting
Library
Kitchen
Programming
Private
Courtesy of Ken Auer,
RoleModel Software, Inc.
©A. Cockburn 2008
Mindset
26
Use “information radiators”
Photos courtesy of ThoughtWorks
©A. Cockburn 2008
Mindset
27
Use “information radiators”
A task model shows workflow, supports release planning and
incremental development
©A. Cockburn 2008
27
28
Use “information radiators”
Navigation Maps and Storyboards describe user interactions
©A. Cockburn 2008
Mindset
29
People are non-linear, spontaneous
Weak on:
Discipline
Consistency
Changing habits
Following instructions
Strong on:
Communicating
Looking around
Copy / modify
Motivated by:
Pride in work
Pride in contributing
Pride in accomplishment
©A. Cockburn 2008
Mindset
30
Speed the team by aligning goals
Normal team
Aligned team
(Dirty Dozen)
©A. Cockburn 2008
Mindset
31
Amicability speeds information flow
Amicability = Willingness to listen with good will
©A. Cockburn 2008
Mindset
32
People issues determine a project’s speed
Can they easily detect something needs attention?
(Good at Looking Around)
Will they care enough to do something about it?
(Pride-in-work; Amicability)
Can they effectively pass along the information?
(Proximity; face-to-face; convection currents)
©A. Cockburn 2008
Mindset
33
Crystal’s Genetic Code
Mindset
Design priorities
Project properties
Samples
Key Techniques
Design principles
Software development is a
Cooperative Game
of Invention and Communication
©A. Cockburn 2008
Design priorities
34
Crystal’s Genetic Code
Mindset
Design priorities
Project properties
Samples
Key Techniques
Design principles
Project Safety
Development Efficiency
Process Habitability
©A. Cockburn 2008
Project properties
35
Crystal’s Genetic Code
Mindset
Design priorities
Project properties
Samples
Key Techniques
Design principles
The Seven Properties of Successful Projects
©A. Cockburn 2008
Project properties
36
Seven Properties of Successful Projects
Frequent delivery
1
2
3
Have you delivered running,
tested, usable functions to
your users at least twice
in the last six months?
7
4
5
6
©A. Cockburn 2008
Project properties
37
Seven Properties of Successful Projects
Frequent delivery
1
Reflective improvement
2
3
Did you get together within the last
three months to discuss and
improve your group's
working habits?
7
4
5
6
©A. Cockburn 2008
Project properties
38
Seven Properties of Successful Projects
Frequent delivery
1
7
Reflective improvement
2
Close communication
3
Does it take you under 30 seconds
to get your question to the attention
of the person who might have
the answer?
Do you overhear something relevant
from a conversation among
other team members
every few days?
4
5
6
©A. Cockburn 2008
Project properties
39
Seven Properties of Successful Projects
Frequent delivery
1
Reflective improvement
2
Close communication
3
Can you give your boss bad news?
Can people end long debates about
each other’s designs with
friendly disagreement?
7
4
Personal safety
5
6
©A. Cockburn 2008
Project properties
40
Seven Properties of Successful Projects
Frequent delivery
1
Reflective improvement
2
Close communication
3
Does each person know what their
top two priority items are?
Are they guaranteed at least
two days in a row with
two uninterrupted hours each day
to work on them?
7
4
Personal safety
5
Focus
6
©A. Cockburn 2008
Project properties
41
Seven Properties of Successful Projects
Frequent delivery
1
Reflective improvement
2
Close communication
3
Does it take less than three days
from when you have a question
to when an expert user
answers it?
4
Personal safety
... a few hours?
7
5
Focus
6
Easy access to expert users
©A. Cockburn 2008
Project properties
42
Seven Properties of Successful Projects
Frequent delivery
1
Reflective improvement
2
Close communication
3
Do your developers use
the configuration management
system?
Are your tests automated?
4
Personal safety
Do you integrate the system
at least twice / week?
7
5
Technical environment
Focus
6
Easy access to expert users
©A. Cockburn 2008
Project properties
43
Seven Properties of Successful Projects
Frequent delivery
1
Reflective improvement
2
Close communication
3
4
Personal safety
7
5
Technical environment
Focus
6
Easy access to expert users
©A. Cockburn 2008
Project properties
44
Crystal is based on the first three
Frequent delivery
1
Reflective improvement
2
Close communication
3
4
Personal safety
7
5
Technical environment
Focus
6
Easy access to expert users
©A. Cockburn 2008
Design principles
Crystal’s Genetic Code
Mindset
Design priorities
Project properties
Samples
Key Techniques
Design principles
Every project is different ...
We need a family of tunable methodologies,
... each satisfying the design priorities
and project properties.
©A. Cockburn 2008
45
Design principles
Crystal uses 7 design principles
•
•
•
•
•
•
•
Face-to-face communication is most efficient.
Methodology weight is costly.
Add weight with project size and distance.
Add ceremony with project criticality.
Add feedback & communications
to reduce intermediate deliverables.
Add discipline, skills, understanding
to offset process, formality, documentation.
Trade efficiency at non-bottleneck stations.
©A. Cockburn 2008
46
Design principles
Modern projects run in nested cycles.
Project
Delivery
Iteration
Day/Week
Integration
©A. Cockburn 2008
47
Design principles
48
Describe each cycle independently.
Project
Delivery
Delivery
Iteration
Week/Day
Integration
Iteration
Iterations
Week
Integrations
©A. Cockburn 2008
Design principles
The basic anatomy of an Agile cycle
plan
perform
evaluate
©A. Cockburn 2008
49
Design principles
The basic anatomy of an agile cycle
Iteration Planning
Meeting
Iteration Plan
Features or User
Stories
Development Task
Creation
Estimation
plan
An Agile iteration is
generally 1-4 weeks, or 1
calendar month
objective: plan, create,
and validate finished
functionality
perform
evaluate
Development
supported by:
• automated unit
tests
• automated
acceptance tests
Product Demonstration
Creation of Additional
User Stories
Measurement of Team
Velocity
Team Retrospective
©A. Cockburn 2008
50
Design principles
Agile planning is done in layers
©A. Cockburn 2008
51
Design principles
52
Agile planning is done in layers
Product
or Project
What business objectives
will the product fulfill?
Product Charter
Elevator Pitch
Release
How can we release
value incrementally?
What subset of business
objectives will each
release achieve?
What user constituencies
will the release serve?
What general capabilities
will the release offer?
Release plan
Iteration
What specifically will we
build? (features or user
stories)
How will this iteration
move us toward release
objectives?
Iteration Plan
Feature or User Story
What user or stakeholder need will
the story serve?
How will it specifically look and
behave?
How will I determine if it’s
completed?
Feature or Story Details
Acceptance Tests
©A. Cockburn 2008
Design principles
53
The Planning Onion can grow to include
product portfolios and business strategy
Product
or Project
What business objectives
will the product fulfill?
Product Charter
Elevator Pitch
Release
Product or Project
Release
Iteration
How can we release
value incrementally?
What subset of business
objectives will each
release achieve?
What user constituencies
will the release serve?
What general capabilities
will the release offer?
Release plan
Iteration
What specifically will we
build? (features or user
stories)
How will this iteration
move us toward release
objectives?
Iteration Plan
Feature
Feature or User Story
What user or stakeholder need will
the story serve?
How will it specifically look and
behave?
How will I determine if it’s
completed?
Feature or Story Details
Acceptance Tests
©A. Cockburn 2008
Design principles
54
The Planning Onion can grow to include
product portfolios and business strategy
Product or Project
Release
Iteration
Feature
© 2006-2007 Jeff Patton, All rights reserved,
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
©A. Cockburn 2008
54
Design principles
55
The Planning Onion can grow to include
product portfolios and business strategy
Business Strategy
Product Portfolio
Product or Project
Release
Iteration
Story
© 2006-2007 Jeff Patton, All rights reserved,
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
©A. Cockburn 2008
55
Design principles
56
An iteration has it’s
plan-perform- evaluate cycle
perform
Iteration
plan
evaluate
© 2006-2007 Jeff Patton, All rights reserved,
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
©A. Cockburn 2008
56
Design principles
Performing an iteration means discussing, writing
code for, and validating features or user stories
code
Feature
design
perform
validate
Iteration
plan
evaluate
©A. Cockburn 2008
57
Design principles
Releasing software incrementally means
building software iteratively
code
Feature
design
validate
Iteration
plan
evaluate
Release
plan
evaluate
©A. Cockburn 2008
58
Design principles
Chartering a product or project means
determining how to release it incrementally
code
precise, fine
grained,
detailed
Feature
design
validate
All this planning
and evaluation
lends lots of
opportunity for
course correction
Iteration
plan
evaluate
Release
plan
abstract,
course
grained,
and high
level
plan
Notice the layers of
planning and
evaluation
evaluate
Product/Project
evaluate
Notice how
planning and
evaluation moves
from course grain
to fine grain, and
from abstract to
detailed
©A. Cockburn 2008
59
Design principles
This model is often drawn using the “day” as
the smallest element of planning
This is often called
a snowman model
code
precise, fine
grained,
detailed
design
Feature
Day
validate
Iteration
plan
evaluate
Release
plan
abstract,
course
grained,
and high
level
plan
60
evaluate
Product/Project
evaluate
©A. Cockburn 2008
Design principles
61
We can flatten these nested cycles to see how
they look over time.
product
release
release
iteration
daily story
development
cycles
time
© 2006-2007 Jeff Patton, All rights reserved,
©A. Cockburn 2008
61
Design principles
62
For very long release cycles sometimes an interim cycle is
inserted to add additional planning and evaluation
product
release
milestone
milestone
iteration
daily story
development
cycles
time
© 2006-2007 Jeff Patton, All rights reserved,
©A. Cockburn 2008
62
Design principles
People in Agile projects typically fall into 3
general roles
Product Owner, or Customer
The Development Team
The Coach or Scrum Master
©A. Cockburn 2008
63
Design principles
The Agile Product Owner or Customer steers the
product
Product Owner role name comes from Scrum
Customer role name comes from Extreme
Programming
This is a role that can be held by a single
person,
but is generally supported by a team:
o
o
o
o
o
o
Business Analysts
UI Designers & Interaction Designers
Architects
Testers
Domain Experts
Users
©A. Cockburn 2008
64
Design principles
65
The team builds and tests software and anything
else needed to support it
The Team is generally composed of
o
o
o
o
o
Developers
Architects
Testers
Business Analysts
UI Designers & Interaction Designers
Some members of the team support both the
product owner team, and the development
team.
©A. Cockburn 2008
65
Design principles
The Scrum Master or Coach oversees, facilitates,
and helps the team peform
The Scrum Master or Coach helps keep the
process running smoothly
o makes sure everyone understands their roles and
responsibilities
o helps team members get help and training
o deals with problems or impediments that slow the
team down
o facilitates planning, product evaluation, and
retrospective meetings
Often this person used to be a project manager
in a traditional software development
approach
©A. Cockburn 2008
66
Design principles
67
Methodologies are transient
Ecosystem
Methodology
Activities
Quality
Values
Milestones
Process
Products
Techniques
Standards
Tools
Values
Teams
Jim
Peter
Jenny
Annika
Tester
Designer
Documenter
Project manager
Roles
Skills
Methodologies are abstractions
People
Personality
People are real
©A. Cockburn 2008
Design principles
A “methodology” is nothing
more than the conventions
people agree to follow !
They naturally drift over time
©A. Cockburn 2008
68
Design principles
Revisit your conventions every month
Criticality
Life
Essential
moneys
Discretionary
moneys
L6
L20
X
E6
X
D6
L100
E40
E100
X
E20
X
L40
X
D20
D40
D100
C20
C40
C100
Comfort
C6
1-6
- 20
- 40
- 100
Number of people coordinated
©A. Cockburn 2008
69
Design principles
How do we make methodology
construction so cheap that we can
reconstruct it each month?
©A. Cockburn 2008
70
Design principles
Answer : The Reflection technique
Keep These
Try These
©A. Cockburn 2008
71
Design principles
(defects cause loss of...)
Criticality
Crystal is a family
Life
(L)
L6
L20
L40
L100
Essential
money
(E)
E6
E20
E40
E100
Discretionary
money
D6
(D)
D20
D40
D100
C20
C40
C100
Comfort
(C)
C6
Clear Yellow Orange Red
1-6
- 20
- 40 - 100
Number of people involved
©A. Cockburn 2008
72
Techniques
Crystal’s Genetic Code
Mindset
Design priorities
Project properties
Samples
Key Techniques
Design principles
Any technique is OK !
©A. Cockburn 2008
73
Techniques
Some “interesting” techniques are documented in
Crystal Clear
Reflection Workshop
Methodology Shaping
Blitz Planning
Delphi Estimation
Daily Stand-ups
Agile Interaction Design
Process Miniature
Side-by-Side Programming
Burn Charts
Exploratory 360°
Early Victory
Walking Skeleton
Incremental Rearchitecture
Information Radiators
©A. Cockburn 2008
74
Techniques
75
The reflection workshop takes an hour / month
1. Hang a 2-column flipchart
2. Fill in the chart
(30 - 60 minutes)
3. Post ! the chart in a
frequently seen place
4. Use ! the ideas
5. Repeat ! each month
Keep these
test lock-down
quiet time
daily meetings
Try these
pair testing
fines for interruptions
programmers help testers
Problems
too many interruptions
shipping buggy code
©A. Cockburn 2008
Techniques
It’s useful to arrange techniques based on the
cycle they’re most applicable to
©A. Cockburn 2008
76
Techniques
Daily techniques
Daily standup meeting (Daily Scrum)
Detailed Story Discussions
Pair Programming
Side-by-side Programming
Paired Work
Test Driven Development
Refactoring & Simple Design
Automated Acceptance Testing
Development Task Walls
Day
Iteration
Release
©A. Cockburn 2008
77
Techniques
Iteration techniques
Iteration Planning Meeting
Feature Definition or Story Writing
Iteration Burn Down Chart
End of Iteration Product Demonstration
Iteration Level Product Evaluation
Velocity & Load Factor Measurement
Reflection Session
Day
Iteration
Release
©A. Cockburn 2008
78
Techniques
Release techniques
Release Planning
Release Level Feature Identification or
Story Writing
User Observation & Modeling
Workflow Analysis and Modeling
Business Objective Prioritization
User Acceptance Testing
Usability Testing
Day
Iteration
Release
©A. Cockburn 2008
79
Samples 80
Crystal’s Genetic Code
Mindset
Design priorities
Project properties
Samples
Key Techniques
Design principles
Crystal Orange/web
Crystal Orange
Crystal Yellow
Crystal Clear
2001
1994
2006
1998
©A. Cockburn 2008
Samples 81
Crystal Orange is for 30-50 people, no loss of life
L6
L20 L40 L80
E6
E20 E40 E80
D6 D20 D40 D80
C6
Amber
C20 C40 C80
Teams
Roles
System planning
Monitoring
Architecture
Technology
Functions
Infrastructure
External test
Sponsor
Business expert
Usage expert
Technical facilitator
Business analyst/designer
Project Manager
Architect
Lead designer/programmer
Designer/programmer
UI designer
Design Mentor
Reuse Point
Tester
©A. Cockburn 2008
Samples 82
Crystal Clear is for 3-10 co-located people
E6
Seating
Required Roles
single big room
(or adjacent offices)
sponsor
senior designer
designer/programmer
user (part-time)
E10
Teams
D6 D10
C6 C10
single team of
designer-programmers
Combined Roles
coordinator
business expert
requirements gatherer
©A. Cockburn 2008
83
How do I get started with Crystal ?
©A. Cockburn 2008
84
Select the initial cycle lengths
Project: any length
Delivery: every two months
Delivery
Iteration: two weeks?
Week
Integration: daily
Iteration
Iterations
Week
Integrations
©A. Cockburn 2008
85
Establish the first 3 properties
Frequent Delivery : every month or two
Osmotic Communication : sit next to each other
Reflective Improvement : workshop monthly
©A. Cockburn 2008
86
Stay in good-humored communication
Add ...
Personal Safety
Focus
Easy Access to Expert Users
- Configuration management
- Automated testing
- Frequent integration
©A. Cockburn 2008
87
Reflect monthly
Keep these
test lock-down
quiet time
daily meetings
Try these
pair testing
fines for interruptions
programmers help testers
Ongoing Problems
too many interruptions
shipping buggy code
©A. Cockburn 2008
88
Crystal’s genetic code.
Mindset
Cooperative game of
invention and
communication
Design Priorities
Project safety
Development efficiency
Developer habitability
Project Properties
Frequent delivery
Close communication
Reflective improvement
Design Principles
7, including
face-to-face
concurrent development
reflective tailoring
Techniques
Discretionary
with a starter set
Design Samples
Crystal Clear
Crystal Yellow
Crystal Orange
Crystal Orange-web
©A. Cockburn 2008
89
Read more at
http://Alistair.Cockburn.us
©A. Cockburn 2008
90
Making Agile Development
Crystal Clear
Alistair Cockburn
http://Alistair.Cockburn.us
Jeff Patton
http://www.JeffPatton.us
©A. Cockburn 2008
91
The Shape Of This Course
Monday: Foundations for the Crystal Agile Approach
o 9:00 – 10:30: People, Communication, and the Agile Software
Development Cooperative Game
o 11:00 – 12:30: Crystal Agile Process Construction
o 12:30 – 1:30: Lunch
o 1:30 – 3:00: Incremental Thinking Simulation
o 3:30 – 5:00: Communication in Time-Boxed Development
Tuesday: Applying Agile Thinking
o 9:00 – 10:00: Discovering Requirements Incremental in Agile Projects
o 10:30 – 12:00: Collaboratively Planning an Agile Development Cycle
o 12:00 – 1:00: Lunch
o 1:00 – 2:00: The Agile Product Owner Role
o 2:30 – 3:30: Applying Lean Thinking to Agile Development
o 3:30 – 5:00: Reflecting on Your Current Process
©A. Cockburn 2008
92
User Stories
©A. Cockburn 2008
93
Agile development reduced batch size by
breaking up functionality into smaller pieces
Small pieces can be referred to as items in a backlog of
work (backlog items) – or more commonly today as user
stories
User stories are often written on index cards
* Kent Beck coined the term user stories in
Extreme Programming Explained
©A. Cockburn 2008
94
Agile development reduced batch size by
breaking up functionality into smaller pieces
A good story describes
what the system should do
from the users perspective.
©A. Cockburn 2008
95
Agile development reduced batch size by
breaking up functionality into smaller pieces
A good story describes what
the system should do from
the users perspective.
It usually has:
o a title
o a concise problem statement often
written using the template:
As a [type of user]
I want to [perform some task]
so that I can [reach some goal]
o other relevant notes or sketches
©A. Cockburn 2008
96
Stories arrange themselves into a backlog
A collection of stories for a
software product is referred
to as the product backlog
The backlog is prioritized
such that the most valuable
items are highest
©A. Cockburn 2008
97
Stories arrange themselves into a backlog
A collection of stories for a
software product is referred
to as the product backlog
The backlog is prioritized
such that the most valuable
items are highest
©A. Cockburn 2008
98
Highest priority stories can then be built in a
development iteration
©A. Cockburn 2008
99
Allow stories to be large when planning, decompose or split them
as the move closer to being built in an iteration
Release planning
stories may be
roughly estimated in
weeks
product
release
Slice of sections to
develop in earlier
milestones – estimate
at a few days to a
couple weeks
Thin to iteration
level stories
estimated in days
Discussions around
decomposing,
splitting, and thinning
cards add detail.
Record this detail as
the stories are
discussed.
milestone
mile
iteration
daily story
development
cycles
time
© 2006-2007 Jeff Patton, All rights reserved,
©A. Cockburn 2008
100
Allowing stories to vary in size creates a story backlog
where high priority items are more decomposed
Stories ready to
Stories for
current and
place in the
near term
iterations
next iteration or
two should be
thinned to the
Stories for
smallest size
the
current
reasonable
milestone
Stories for an
upcoming release or
milestone
©A. Cockburn 2008
101
A user story goes through a simple lifecycle to
grow to become more like “requirements”
A story goes through a
simple elaboration cycle of:
o card: write the initial story
text on the card
o conversation: discuss the
details with developers,
analysts, and testers
o confirmation: record the
acceptance tests that will
allow us to know when the
story is complete
* Ron Jeffries coined the 3
C’s in Extreme Programming
Installed
©A. Cockburn 2008
102
The quality of stories or backlog items
can be evaluated
The INVEST test allows us to evaluate our stories:
o Independent: can I (ideally) schedule the story at any time?
Does it depend on any other story to be valuable?
o Negotiable: can we resolve the details during discussion to
arrive at the most economical solution?
o Valuable: does the story add value to the product? Does it
move it closer to achieving its goals?
o Estimable: can the story be estimated? Roughly given a few
detail, and more accurately given acceptance criteria we arrive
at during discussion?
o Small: can it be developed and
tested in a reasonable amount to
time? A couple days to a couple
weeks is good.
o Testable: can we verify the story
is complete using acceptance
criteria we agree on?
* Bill Wake coined the INVEST approach to testing story quality
©A. Cockburn 2008
102
103
Use the term that best fits your organization…
User story
Feature
Backlog item
Work Package
MMF: minimal marketable feature
©A. Cockburn 2008
104
Blitz Planning
©A. Cockburn 2008
105
Hold a Blitz Planning Session or Planning Jam
Session
Setup
1.
2.
3.
Identify cycle time frame
o weeks to months, iteration, milestone, or release
Identify cycle goals
o When the work is delivered, what goals do we expect to meet? Or, what
problems do we hope to solve
Identify large pieces of functionality in scope
o
4.
Features or user stories to be delivered
Brainstorm work tasks
o Call out tasks as you record them on card – no discussion
©A. Cockburn 2008
106
Hold a Blitz Planning Session or Planning Jam
Session
Plan
1.
Lay out tasks chronologically
o Mark the top of the table with the start
date, the bottom with the end date
2. Review the tasks
o Look for missing tasks or duplicate
tasks. Split tasks.
3. Annotate tasks
o Add additional details such as
required person to perform, time
estimate, description, dependency
4. Identify a thinnest complete piece of
functionality - the walking skeleton
©A. Cockburn 2008
107
Hold a Blitz Planning Session or Planning Jam
Session
1.
2.
3.
Identify cycle time frame
o weeks to months, iteration, milestone, or release
Identify cycle goals
o When the work is delivered, what goals do we expect to meet? Or, what
problems do we hope to solve
Identify large pieces of functionality in scope
o
4.
5.
6.
7.
8.
Features or user stories to be delivered
Brainstorm work tasks
o Call out tasks as you record them on card – no discussion
Lay out tasks chronologically
o Mark the top of the table with the start date, the bottom with the end date
Review the tasks
o Look for missing tasks or duplicate tasks. Split tasks.
Annotate tasks
o Add additional details such as required person to perform, time estimate,
description, dependency
Identify a thinnest complete piece of functionality - the walking skeleton
©A. Cockburn 2008
108
Apply (light weight) Lean thinking to Agile
Incremental development using Kanban
©A. Cockburn 2008
109
看板 – Kanban cards help limit excess work in
progress
看板 – Kanban literally means
visual card
In its initial development it was
used to limit the amount of
inventory tied up in “work in
progress” on a manufacturing
floor
Not only is excess inventory
waste, time spent producing it is
better spent elsewhere
In software development visual
cards on a board are used to:
o limit work in progress
o point out bottlenecks in process
flow
©A. Cockburn 2008
110
1. defining a work process flow
This simple process flow has the
steps:
1. elaboration & acceptance
2. development
3. test
4. Deployment
Look at the typical flow for features, stories, or work
packages and describe typical process steps
©A. Cockburn 2008
111
2. Lay out the kanban board
Place an expedite track above the
main left to right queue
Place “done and waiting” queues
between each work queue
(in this example they’re placed below)
Place a goals column on the left, and waiting queue,
the process steps, and a final “done” column
©A. Cockburn 2008
112
3. Decide on limits for stories in queue & work in
progress
This board uses painters tape to
indicate available “slots” for work in
progress
A good limit might the number of people in a role that
can work on an item in a given process step
©A. Cockburn 2008
113
4. Place prioritized goals on the left column of the
board
Having goals visible:
• promotes focus
• helps us prioritize
• helps us manage feature scope &
requirements
A good goal describes the outcome we hope to
achieve after software ships
©A. Cockburn 2008
114
5. Start the board by placing stories or features in
queue
Product owners manage the waiting
queue
Mark on the story or feature card with the date it
entered the queue
©A. Cockburn 2008
115
6. Move stories through the process flow as work
is completed
As the story enters the first process step, mark that
date on the card. As it’s finished, mark that date on
©A. Cockburn 2008
the card
116
Use the dates on the cards to calculate cycle time
Cycle time = finish date – start date
The average cycle time from the
date the item enters the board is
the wait time from this point in the
queue
Use average cycle time to set wait times from different
points on the board
©A. Cockburn 2008
117
Kanban Boards
©A. Cockburn 2008
118
Kanban Boards
©A. Cockburn 2008
119
Explode large process steps into tasks
When a feature or work task is large:
o Takes longer than a couple days to complete
o Requires that multiple people collaborate on it’s completion
Decompose that step into cards to track independently
Feature to
develop
Tasks in
queue
Tasks in
progress
Tasks
complete
Feature
complete
©A. Cockburn 2008
120
Kanban Boards
©A. Cockburn 2008
121
Use cumulative flow diagrams to visualize work in
progress
www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
©A. Cockburn 2008
122
Use cumulative flow diagrams to visualize work in
progress
www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
©A. Cockburn 2008