Feedback Loops in Agile Development

Feedback Loops in Agile
Development
from the basic concepts to a prescriptive start

Jamie Allsop

http://www.agile-trac.org

Who Am I
● On a payroll running distributed agile teams since 2004
● Worked across different sectors in the software industry,
from coding specialised DSP algorithms to delivering
financial products worth 10s of millions in revenue
● Currently in a company hoping to scale revenue
significantly within the next two years by scaling and
growing their software products
● C++ Developer and co-author of a book on C++
● Creator of agile-trac plugin

Overview
● Setting the context...Typical Development
● And why it can suck
● Enter Agile Development...and useful Feedback
● What an Agile Methodology entails
● User Stories
● Agile Estimating and Planning
● Feedback in Agile Development
● Tool Support and Practices
● Source Control Management
● Automation, Automation, Automation
● A Brief Prescription

Typical Development
● Inputs to development are usually
● Product Requirements Documents from marketing and business
development (new development)
● Ticket Issues from customers (continuing development)
● Product Requirements Documents
● full product specification generated up front
● used by development to create a Software Requirements Document
● Transform Requirements Documents into a Development Plan
● develop a Gantt chart and Spreadsheets to provide an estimate of
the work involved, typically covering a full release
● Progress measured by Task Completion per Resource
● Ticket Issues generally become deviation points for the plan

Typical Development
● Inputs to development are usually
● Product Requirements Documents from marketing and business
development (new development)
Gat
Gat ed I
ed In
Ticket Issues from customers (continuing development)
●

nputs
puts
Product Requirements Documents
used
●

full product Task
Task used
to D
Deli to De
specification generated up front
Dtolcreate a Software r
e ive
●

very
ry = P eriive
= Prointo ve Task
● used by development Requirements Document
●
r gre Tasks
Transform Requirements Documentsog a Development Plan
ress s
●
ss
develop a Gantt chart and Spreadsheets to provide an estimate of the
work involved, typically covering a full release
● Progress measured by Task Completion per Resource
● Ticket Issues generally become deviation points for the plan

Problems with Typical Development
● Tasks are hard to trace to business value
● Emphasis is on following a plan
● The Plan is always out-of-date - changing it is heavyweight
● Very difficult to assess where we are NOW
● Incremental delivery of Product is hard as Tasks are not
aligned with User Value
● Incoming Issues deflect and interrupt the Plan – poor
integration
● Emphasis on where we would like to be: not where we are,
or where we could be. Basically “wishful planning”

Very difficult to assess where we are NOWllan
P an
P
nhard e Tasksaare not
iin Th e
tais Thas rhe ad
●

Incremental delivery of Product a
maiin t
an he d
full to m ve tiime ove r
aligned with aiin fu to e ove
●

Pa n
PUser Value
iive t m
mass interrupt the Plan – poor
ass
Incoming Issueses a a mand
uiir es
Req u r deflect
integration q
●

Re

Some where we are NOW n
S assess
Very difficult to ometim
times
es man iin T h e Plla n
he P a
●

n aniifeTt erhe ad
mtaisfhard as Tasksaare not
Incremental delivery of Product a nes
Protje maiint
Proto c a he d
full jo ct Mvan tiimseeod er
e m Ma t ov a
m v s
e ed as
●

aligned with aiin fu
User Value t
n
Pa
P nt r
ssiive agers
e ag e
a ma ss interrupt the Plan – poor
deflect a
Incoming Issueses a mand
iir es s
Requ r
Re u
integration q
●


Progress is Measured Against the
First, and Most Inaccurate, Estimate
● Garbage in – Garbage Out
● ISO 9001 – Clean Pipes, Dirty Water
– Focus on how things are done, not why things are done
● RAG status – How we are doing against our most
inaccurate estimate?
– Green for the lifetime of a delivery but still be late? R
– Red for the lifetime of a delivery but be early? A
– What does late and early actually mean?
– We can base 'performance' metrics on this data G
● Focus on gated delivery and traceability
● Often unclear what's done and what's not

Progress is Measured Against the
First, and Most Inaccurate, Estimate
● Garbage in – Garbage Out
● ISO 9001 – Clean Pipes, Dirty Water
– Focus on how things are done, not why things lu a eue
lare done
Va
d V our most
RAG status – How we are doingiite d te
against
Liim
●

inaccurate estimate?
of Lm
– Green for the lifetime of ck
of
ba ck R
baadelivery but be early?
a delivery but still be late?
– Red for the lifetimed
ee d
ee of
Fand early actually mean?
F A
– What does d

iim
m te d
te late
iibase 'performance' metrics on this data G
LL
– We can

● Focus on gated delivery and traceability
● Often unclear what's done and what's not

Just iterating is not enough...
● Bad data more often, doesn't make it good data
● Reacting more often to bad data is worse
● Reinforces bad habits
● Insufficient time and freedom to make positive
changes
● Lack of useful data to build feedback loops
gives you the overhead of iterations without the
benefits
● Keeping plans up-to-date is very expensive

Just iterating is not enough...
● Bad data more often, doesn't make it good data
● Reacting more often to bad data is worse
Reinforces bad habits
nent
a ne nt
●

Perto a
erm make positive
P m
●
akes
M akes ct
Insufficient time and freedom
tiice M erfe ct
changes Prac t ce
Prac NOT P erfe
TP
●
NO build feedback loops
Lack of useful data to
gives you the overhead of iterations without the
benefits
● Keeping plans up-to-date is very expensive

What can we do?
● Shift our focus from Plans that deliver Tasks
● Instead focus on Planning and Value delivery
● Observe and learn from Feedback paths
● Avoid reacting to bad data
● Understand what has been delivered
● Have a view on what is still left to be done
● Easier said than done...

What can we do?
● Shift our focus from Plans that deliver Tasks
Instead focus on Planning and Value delivery
p......
●

ellp paths
Observe and learn from Feedback n he
an h
t ca
●

nt c
Avoid reacting to badme n me
op data
ellop
●

ev e been delivered
D ev
Understandille D has
what
gi e
●

Ag
A
● Have a view on what is still left to be done
● Easier said than done...

Agile Development is Value Driven

30% Complete

T3
T2

T1

30% Complete

S1 S2 S3

T3
T2

T1

30% Complete
Little or No User Value

Task to Value Correlation Low

S1 S2 S3

T3
T2

T1

30% Complete
Little or No User Value Means 30% DONE

Task to Value Correlation Low 30% User Value Delivered

S1 S2 S3

T3
T2

T1

30% Complete
Little or No User Value Means 30% DONE

Task to Value Correlation Low 30% User Value Delivered

S1 S2 S3

T3
T2

T1

Selection of Ingredients vs Slices of the Cake

http://www.halfarsedagilemanifesto.org/

Where to begin...?

Where to begin...?
http://www.halfarsedagilemanifesto.org/

d......
sse d
A sse
H
H allf- A
a f-
iing
e ng
of b e
of b
are
w ar e
Be w
Be

Let's try again

Point your browser to

http://agilemanifesto.org/

We All Need Principles
● Early and continuous delivery of valuable software
● Welcome changing requirements
● Deliver working software frequently
● Business people and developers work together
● Trust motivated individuals
● Working software is the primary measure of progress
● Promote sustainable development
● Technical excellence and good design
● Simplicity is essential
● Self-organising teams
● Team reflection and adjustment
● Face to Face Communication is the most effective

● F ee
F
Early and continuous ack
dbac k
eedbdelivery of valuable software
● Welcome changing requirements

● F ee
F
dbac k
k
● eedbac k
F ee dbac
Welcome changing requirements
F

● F ee
F
dbac k
k
● eedbac k
F ee dbac
F k
● F eedbac k
Deliver working software frequentlyee
F dbac

● F ee
F
dbac k
k
● eedbac k
F ee dbac
F k
F eedbac k
F dbac
back
●

●
eedbac k
Business people and developers work together d
F ee
F

● F ee
F
dbac k
k
● eedbac k
F ee dbac
F k
F eedbac k
F dbac
back
●

●
eedbac k
F ee
F
ck
● Feedba ck
Fe
Working software is the primary measure of progress edba

● F ee
F
dbac k
k
● eedbac k
F ee dbac
F k
F eedbac k
F dbac
back
●

●
eedbac k
F ee
F
ck
● Feedba ck
Fe
k
● F eedbac k
Team reflection and adjustment ee
F dbac

● F ee
F
dbac k
k
● eedbac k
F ee dbac
F k
F eedbac k
F dbac
back
●

●
eedbac k
F ee
F
ck
● Feedba ck
Fe
k
● F eedbac k
Team reflection and adjustment ee
F dbac
● Face to Face Communication is the mosteedback
F eedback
effective
F

The Essence of Agile
● Incrementally delivering actual value to the
stakeholders
● Coping deterministically with change: not trying to
protect against it
● Recognising that a productive environment for
developers leads to more productivity in general and
higher quality overall
● Observing how well we work and adapting to make
improvements
● Maximising project transparency, fostering shared
ownership and a shared vision of the project

The Essence of Agile
● Incrementally delivering actual value to the
stakeholders
Coping deterministically with change: not trying to
Ma x
M ax
●

Thi
T im
protecthagainst itimi
is iis
s s ise U
se U
Recognising a mu productive environment for
a ma
that u s ef
sefu
ch b ull Fe
ch b productivity in general and
●

developers leads to more ette Feedba
e tt edb
higher quality overall er p
r plla ack
ck
ace
ce to
to s t
star
Observing how well we work and adapting to make
art
●

improvements t
● Maximising project transparency, fostering shared
ownership and a shared vision of the project

Agile Development in a Nutshell

START

Incubation
Incubation

START

Incubation
Incubation

Initiation
Initiation

START

Incubation
Incubation

Initiation
Initiation

User Stories

Story 12
Story 2
Story 1 Story 17 Story 13
Story 3

Story 6 Story 7

Story 9

Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

START

Incubation
Incubation

Initiation
Initiation

User Stories

Story 12
Story 2
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

START

Incubation
Incubation

Initiation
Initiation

Tacit
Knowledge User Stories

Story 12
Story 2
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

START

Incubation
Incubation

Initiation
Initiation

Tacit
Knowledge User Stories

Story 12
Story 2
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

M1 M2 M3 Mn

START

Incubation
Incubation

Initiation
Initiation

Tacit Shared
Knowledge User Stories Vision
Story 12
Story 2
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

M1 M2 M3 Mn

START

Incubation
Incubation
User Stories

Iteration Planning
Iteration Planning
Initiation
Initiation

Tacit Shared
Story 12
Story 2
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

M1 M2 M3 Mn

START Iteration Development
Iteration Development
Incubation
Incubation
User Stories
Design
Task List Write Tests
Code
Iteration Planning
Iteration Planning Refactor
Initiation
Initiation User Doc
Acceptance Tests Use
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Story 12
Story 2
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

M1 M2 M3 Mn

Incubation
Incubation
User Stories
Design
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 2
Story 12
& Documentation
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

M1 M2 M3 Mn

Incubation
Incubation Tacit
User Stories Knowledge Design
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 2
Story 12
& Documentation
Story 3

Architecture
Story 6 Story 7

Story 9
Architecture
Story 14 Story 4
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

M1 M2 M3 Mn

Incubation
Incubation Tacit
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 2
Story 12
& Documentation
Story 3

Architecture
Story 6 Story 7

Architecture
Story 14
Story 9

Story 4
Iteration Review
Iteration Review
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19
Story 24
Story 20

M1 M2 M3 Mn

Incubation
Incubation Tacit
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 2
Story 12
& Documentation
Story 3

Architecture
Story 6 Story 7

Architecture
Story 14
Story 9

Story 4
Iteration Review
Iteration Review
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19

Iteration Retrospective
Story 24
Story 20

M1 M2 M3 Mn

Incubation
Incubation Tacit
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 2
Story 12
& Documentation
Story 3

Architecture
Story 6 Story 7

Architecture
Story 14
Story 9

Story 4
Iteration Review
Iteration Review
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18
Story 22
Story 23
Story 21
Story 25 Story 19

Story 24
Story 20

Ownership
M1 M2 M3 Mn
Evolution

Incubation
Incubation Tacit
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 12
& Documentation
Story 2
Issues
Issues POs
Defects POs
Requests
Story 3
User Stories

Architecture
Story 6 Story 7

Architecture User Story

Story 14
Story 9

Story 4
M1 M2 M3 GA Mn User Story
User Story Iteration Review
Iteration Review
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18

Release Planning
Story 22

Release Planning
Story 23
Story 21
Story 25 Story 19

Story 24
Story 20

Ownership
M1 M2 M3 Mn
Evolution

Incubation
Incubation Tacit
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 12
& Documentation
Story 2
Issues
Issues POs
Defects POs
Requests
Story 3
User Stories

Architecture
Story 6 Story 7


Story 14
Story 9

Story 4
Iteration Review
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18

Release Planning
Story 22

Release Planning
Story 23
Story 21
Story 25 Story 19

Story 24
Story 20

Shared
Vision Ownership
M1 M2 M3 Mn
Evolution

START ITERATE Iteration Development
Incubation
Incubation Tacit
Code
Iteration Planning
Initiation
Initiation User Doc
Cases

y
da
Update

1
Status Test
Tacit Shared Cases
Working Software
Story 12
& Documentation
Story 2
Issues
Issues POs
Defects POs
Requests
Story 3
User Stories

Architecture
Story 6 Story 7


Story 14
Story 9

Story 4
Iteration Review
Story 10
Story 8 Story 5
Story 16 Story 11
Story 15

Story 12
Story 18

Release Planning
Story 22

Release Planning
Story 23
Story 21
Story 25 Story 19

Story 24
Story 20

Shared
Vision Ownership
M1 M2 M3 Mn
Evolution

Milestones, Iterations & Releases

Milestone A Milestone B

Iteration x Iteration x+1 Iteration x+2

Time




User Stories
Completed
Over Time

Time




User Stories
Completed
Over Time

Time

Release at end
of Iteration Internal
External
Release x




User Stories
Completed
Over Time

Time

Release at end
of Iteration Internal Milestone A
External
Release x Release x+1




User Stories
Completed
Over Time

Time

Release at end
External
Release x Release x+1 Release x+2




User Stories
Completed
Over Time

Time

Release at end
External

Release at end Milestone A
of Milestone Internal
External




User Stories
Completed
Over Time

Time

Release at end
External

Release at end Milestone A
of Milestone Internal
External
Release A?

● Milestones are prioritised collections of User
Stories
● Iterations are fixed-length, time-boxed periods
over which User Stories are Delivered
● Release scope is defined by the User Stories it
contains, not the Iteration it is delivered in
● You may time Releases with Iterations but the
scope will always be bounded by the Stories
● Think of a Release as an Externalised Milestone

● Milestones are prioritised collections of User
Stories
Miilles
M est
tones
on fixed-length, time-boxed periods
Iterations are es Grou
●
Itera
Iterat Group
tiio User p & Pr Delivered
over whichons DeStories&areiiorit
ns Del Pr or
Rellea
Re eas liiver T
ver Th itiise S
se Sto
ses Ex is defined em the UsertStories it
es Ex
Release scope ter hem in
by in T oriies
r es
ternal Tiime-b
●

naliise it is deliveredoin
contains, not the Iterationto Ss e to me-b
Stake oxes
x es
takeho hollder
● You may time Releases with Iterationsdbut the ers s
scope will always be bounded by the Stories
● Think of a Release as an Externalised Milestone

User Stories:
Sized, Measurable Units of Value
● Identifies the need to Deliver Value to a User
without committing to all the details
● Just-In-Time Understanding
● Captures both functional and non-functional
requirements in a uniform way
● Stories Relatively Sized from a fixed scale

1 2 3 5 8 13 20 40 100
A reasonable size to consider Too large to consider for work in an
for work in an Iteration. Iteration. Needs to be split.

User Story Dependency View
Implicit Implementation Ordering
● The flatter this view the more flexible the release planning

Dependency View of User Stories



iings
h ngs
me t h ers
o me t h ers
fe:: S o re ot h
iife S o e ot
of L
t of L n bef or
Fac t
Fac e n bef
happ e
h ap p
ha
h ve to
a ve to


Howe
Howev
ver cle
er clev iings
h ngs
allllow
a ow ' ver SSome t h
er :SSo me t
e : t ory Se others
'Spif iLiif e t ory r pli thers
Spif iL f
o k ng' t befo Se lottiing
act o k ng'ethrou or p it t ng can
F ac t
F app
pp n r efgh
enhbough can
ve to h a
e to h the t
the tr
ree
ha v
ha ee

Split Large Stories as their
Priority Increases
● Large Stories in upcoming milestones should be split
● Stories too big for an iteration must be split
● This is not easy, but improves understanding
● The User Story Tree gets broader and deeper
SystemAdmin should be SourceAdmin should have
able to enjoy an the ability, within the SourceAdmin can
AWESOME automated context of this product, configure which sources
install on Windows 2000, to report on sources are collectable.
XP, 2003 available to the product

SourceAdmin SourceAdmin SourceAdmin
can ... can ... ... can ...
SystemAdmin
... can ...
SourceAdmin
can ...

SystemAdmin
should ... SourceAdmin SourceAdmin
can ... should ...

SystemAdmin
can ...

SystemAdmin
Capability View of User Stories SourceAdmin
will ...
will ...

Split Large Stories as their
Priority Increases
● Large Stories in upcoming milestones should be split
● Stories too big for an iteration must be split
This is not easy, but improves understanding iiew
biilliity V ew
Capa b ty V
pa
ugh the Ca and deepercture
ugh the
●

The Userkiing Th ro
StoryTh ro gets broader chiite cture
Spiik n
Sp g Tree the Ar ch te
ugh the Ar
●

g th r o u g h
piikiin g thro
llllows S p k n
a ow s S
SystemAdmin should be SourceAdmin should have

a
able to enjoy an the ability, within the SourceAdmin can
AWESOME automated context of this product, configure which sources
install on Windows 2000, to report on sources are collectable.
XP, 2003 available to the product

SourceAdmin SourceAdmin SourceAdmin
can ... can ... ... can ...
SystemAdmin
... can ...
SourceAdmin
can ...

SystemAdmin
should ... SourceAdmin SourceAdmin
can ... should ...

SystemAdmin
can ...

SystemAdmin
Capability View of User Stories SourceAdmin
will ...
will ...

From Not Done to DONE
● We want consistent delivery of User Stories
● We plan to deliver User Stories NOT Tasks
● Sizing and Iterations allow us to predict future
work

work 5
1
13 8
2 5
1
8 20
3
3 1
5 2
13 5
3 40 8
5 5 3
2
5 13 8 3 1
8
2 13 1
13 20
20 8 100 5 8 3 13

work 5
1
13 8
2 5
1
3 8 20 Time and Effort
3 1
5 2
13 5
3 40 8
5 5 3
2
5 13 8 3 1
8
2 13 1
13 20
20 8 100 5 8 3 13

work

8 Time and Effort
3 1
5 2
13 5 2
3 40 1
8 3
5 5 3
2 2 8 5
5 13 8 3 1 8 5 3
8
2 13 1 13 5 1
13 20
20 8 100 13
5 8 3 13 8 8

Planning to Deliver

“Planning is everything, plans are nothing”
● Agile focuses on the practice of planning but
avoids trying to follow a plan
● We do planning to help us understand where we
might be in the future, based on what we know
today, and what we observed in the past
● Planning allows us to continually update our view of
the future for the short, medium and long term
● In Agile we plan at several levels and throughout
the development of a product

Planning to Deliver

“Planning is everything, plans are nothing”
● Agile focuses on the practice of planning but
avoids trying to follow a plan
rst and
dwhattwed
We do planning to help us understandawhere we
n de rs n know
might be in the future,etter u n e
●

b et t er u
to b based on atiing
e whatd toobservedtiin the ng
needwe
today, W e nee d Est im at past
W
and n Es m
niing a nd
● Pllan n nto a
P an us g continually update our view of
Planning allows
the future for the short, medium and long term
● In Agile we plan at several levels and throughout
the development of a product

Understand Different Levels of Planning


Strategy


Strategy

Portfolio

Product is composed of Releases

Strategy

Portfolio

Product


Milestone 1

Strategy

Portfolio

Product

Release


Milestone 1 Milestone 2 is Release 1.0

Strategy

Portfolio

Product

Release


Milestone 1 Milestone 2 is Release 1.0 Milestone 3

Strategy

Portfolio

Product

Release



Strategy

Portfolio

Product

Release
Iteration 1



Strategy

Portfolio

Product

Release
Iteration 1
Iteration
Task Time
Design X 1 hour
Implement X ½ day
Implement Y 4 days
Meetings 1 hour
Automate Tests 2 days



Strategy

Portfolio

Product

Release
Iteration 1
Iteration
Task Time
Design X 1 hour
Implement X ½ t?
day
midays
m4
Implement Y Co
MeetingsC
an 1 hour



Strategy

Portfolio

Product

Release
Iteration 1 Iteration 2
Iteration
Task Time
Design X 1 hour
Implement X ½ t?
day
midays
m4
Implement Y Co
MeetingsC
an 1 hour



Strategy

Portfolio

Product

Release
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Iteration
Task Time
Design X 1 hour
Implement X ½ t?
day
midays
m4
Implement Y Co
MeetingsC
an 1 hour



Strategy

Portfolio

Product

Release
Iteration
Task Time Daily
Design X 1 hour Story Active Done
Implement X ½ t?
day
midays
OpsUser ...
Implement Y Co m4 SysAdmin ...
MeetingsC
an 1 hour Trader ...



Strategy

Portfolio

Product

Release
Iteration
Task Time Daily
½ t?
Implement X day
midays
OpsUser ...
?
m4 ues
Implement Y
an
Co SysAdmin ... I ss
MeetingsC 1 hour Any
Trader ...



Strategy

Portfolio

Product

Release
Iteration
Task Time Daily
½ t?
Implement X day
midays
OpsUser ...
?
m4 ues
Implement Y
an
Co SysAdmin ... I ss
MeetingsC 1 hour Any
Trader ...
Automate Tests 2 days The 'Planning Onion' shows
how the different levels of
planning are layered

Understand Estimating
● People generally give poor 160 %

estimates for how long
they think something will take 100 %
● The larger or further away
Knowledge, Iterations Observed
something is the less 60 %

accurate the estimation
● However people generally are consistent with their poor
estimates
● They get their estimates consistently wrong
● If we decouple the estimation from the representation of the
time the estimate means, we can have quite accurate
estimates

Splitting Stories as an Example

Large Story
Not Well Understood


Large Story Split Large Story to
Not Well Understood Smaller Stories


?



?
Rescoping Improves
Understanding



?
Rescoping Improves
Understanding


Refinement Improves
Understanding

Smaller Stories means Better Estimates
● It has been shown that in general people are better
at estimating smaller things
● A single 100 sized story will take longer than a number of
smaller stories with the same total size
● The cone of uncertainty supports this
● However when splitting beware of creating gaps in
story coverage
● Splitting can also help clarify scope
● The total size may increase after splitting but the size
needed to be accomplished within the same milestone is
often less – only some of the stories are needed now

Smaller Stories means Better Estimates
● It has been shown that in general people are better
at estimating smaller things
For U
A single 100 sized story will take longer than a number of
Fostories with the same total size
●

smaller r User
se
r Stor
Stor
Must uncertaintyiies
Musofk
The cone t kn es to b
●
now w
ow wh to be
supports this
e usef
● However when splitting n the ofusefull we
he n t
e beware creating gaps in
hey ar u we
story coverage y are D
e DON
ONEE
● Splitting can also help clarify scope
● The total size may increase after splitting but the size
needed to be accomplished within the same milestone is
often less – only some of the stories are needed now

The Discipline of DONE
● Learn how to articulate when a Story is DONE
● This is more than just saying “I'm finished”
● Assumes detailing the precise scope of what
has been, or was supposed to be, achieved
● Means learning to go from the easy 80%
finished to cover that elusive last 20%
● Ensures that we are truly, incrementally,
delivering value
● Implies knowing when to defer scope for later

The Discipline of DONE
● Learn how to articulate when a Story is DONE
● This is more than just saying “I'm finished”
Assumes detailingnthetatement t o profciiselly
e se y
o precwhat
●
S tement t
tprecise scope
lletiion S a
pwasosupposed totbe,yachieved
om p et
a C oor
hasse a C
Us e m DONE
o r y D O NE
akes a S tor
been,
U m akes a S
ate whatgo from the n pllanniing
e what m
Meansdlearning to of iiteratiioeasy nn ng
iin diic at
n c
●
at on p a 80%
art of ter last 20%
finished hiiscover rt elusive
T h s iis p a that
Tto s p
● Ensures that we are truly, incrementally,
delivering value
● Implies knowing when to defer scope for later

So Where Are We?
● We have Relatively Sized User Stories
● Both Functional and Non-Functional
● We have Time-Boxed Iterations
● In which we deliver User Stories
● We have prioritised Milestones
● Which are groups of User Stories
● We can identify what a Release will be
● Either the result of an Iteration or a Milestone
● We know how we can plan at different levels and that
estimates can be relative and decoupled from time

So Where Are We?
● We have Relatively Sized User Stories
● Both Functional and Non-Functional
● We have Time-Boxed Iterations
ther......
toge ther
allll toge
● In which we deliver User Stories
th s a
We have prioritised ullll thiis
me to p u
Tiime to p
Milestones
●

T
● Which are groups of User Stories
● We can identify what a Release will be
● Either the result of an Iteration or a Milestone
● We know how we can plan at different levels and that
estimates can be relative and decoupled from time

Consistently Inaccurate Historical Data
can be a very good Estimator
● This is because there are many feedback loops
at play in Agile Development
● Ensuring that observed data based on
decoupled estimates can oscillate towards
accurate estimates
● The key is to consistently make similar estimates
and allow the 'completion rate' to compensate for
inaccuracy
● Use the principles of the 'cone of uncertainty' to
provide Date Range Estimates for future dates

Consistently Inaccurate Historical Data
can be a very good Estimator
● This is because there are many feedback loops
at play in Agile Development
● Ensuringethat observed data based on
L et's llook
L t's ook ag
aga cant plan
decoupled estimatesiin at oscillate towards
a n a planni
diifferent
d fferent le ning at
ng a t
lev e s thi t
accurate estimates ells,, this
v
attentiion s tiime payin
me p a y i g
atttonconsistently make similarnestimates
The key is e t on to fe
to feedback g
edback lloop
●

and allow the 'completion rate' to oops s
compensate for
inaccuracy
● Use the principles of the 'cone of uncertainty' to
provide Date Range Estimates for future dates

Planning and Feedback
Identify
Identify
Milestones
Milestones Release Planning provides the long
term strategic and product view
Issues
Issues POs
User Stories Issues POs
POs Release Planning
User Story
User Story

Identify
Identify Prioritise
Prioritise
Releases
Releases Milestones
Milestones

Identify
Identify
Milestones
Issues
Issues POs
User Story
User Story

Identify
Identify Prioritise
Prioritise
Releases
Releases Milestones
Milestones Candidate
Candidate Iteration Planning provides
Stories
Stories
prioritised short term view

User Stories Iteration
Expand
Expand
Estimate if
Estimate if Stories
Stories
can commit
can commit

Identify
Identify
Milestones
Issues
Issues POs
User Story
User Story

Identify
Identify Prioritise
Prioritise
Releases
Releases Milestones
Stories
Stories

Expand
Expand
Estimate if
Estimate if Stories
Stories
can commit
can commit
Doc
Doc

Accept
Accept
Task List
Code
Code Daily
Use
Test Cases
Cases

Test Refactor
Refactor
Test

Design
Design

Identify
Identify
Milestones
Issues
Issues POs
User Story
User Story

Identify
Identify Prioritise
Prioritise
Releases
Releases Milestones
Stories
Stories

Iteration
Iteration Expand
Expand
content affects
content affects Estimate if
Estimate if Stories
Stories
release times
release times can commit
can commit
Doc
Doc

Accept
Accept
Task List
Code
Code Daily
Use
Test Cases
Cases

Test Refactor
Refactor
Test

Design
Design

Identify
Identify
Milestones
Issues
Issues POs
User Story
User Story

Identify
Identify Prioritise
Prioritise
Releases
Releases Milestones
Stories
Stories

Iteration
Iteration Expand
Expand
content affects
Estimate if Stories
Stories
release times
can commit
Doc
Doc

Accept
Accept
Task List
Code
Code Daily
Use
Test
DONE Stories
DONE Stories Cases
Cases
move towards
move towards
Test Refactor
Refactor
releases
releases Test

Design
Design

Identify
Identify
Milestones
Issues
Issues POs

elliivery
D e very
User Story
User Story

Story D
t St o r y
llook a t
Identify
Identify Prioritise

's ook a
Prioritise

payiing
p ay n g
Releases
Releases Milestones Candidate

et 's

llet
Iteration Planning provides

N ow
Now e m or e
iim e more k
Stories
Stories

,, thiis t m
iin th s t edbac k
aga n
aga Fe edbac
Iteration

iion to Fe
User Stories

nt on to
Iteration Expand

atte nt
Iteration Expand

a tte
content affects
Estimate if Stories
Stories
release times
can commit
Doc
Doc

Accept
Accept
Task List
Code
Code Daily
Use
Test
DONE Stories
DONE Stories Cases
Cases
move towards
move towards
Test Refactor
Refactor
releases
releases Test

Design
Design

Story Delivery and Feedback

Stories Added
Stories Added
Initial Idea
to Iteration
to Iteration

As Iterations are
Roadmap
Roadmap completed and stories Stories DONE
Stories Captured
Stories Captured Stories DONE
Content
Content DONE we better
in Iteration
& Relatively Sized
& Relatively Sized understand our in Iteration
Updated
Updated product

Roadmap
Roadmap
Dates
Dates
Updated
Updated


Stories Added
Stories Added Better at
Initial Idea Stories may need to Iteration
to Iteration estimating
to be split or what we can
scope refined commit to

As Iterations are
Roadmap
Roadmap completed and stories Stories DONE
Stories Captured
Stories Captured Stories DONE
Content
in Iteration
& Relatively Sized
& Relatively Sized understand our in Iteration
Updated
Updated product

As Roadmap Roadmap
Roadmap
content changes
dates are
Dates
Dates
updated Updated
Updated


Stories Added
to be split or what we can Iteration
scope refined commit to produces
working
software
As Iterations are
Roadmap
Roadmap completed and stories Stories DONE Useful
Stories Captured
Stories Captured Stories DONE Useful
Content
in Iteration Software
& Relatively Sized
& Relatively Sized understand our in Iteration Software
Updated
Updated product

Working software
As Roadmap Roadmap
Roadmap provides feedback
content changes
dates are
Dates
Dates on what is
required
updated Updated
Updated


Stories Added
to be split or what we can Iteration
scope refined commit to produces

Allll we nee
working

A we need software

Roadmap d to do now i Stories DONE
t o d o n ow s
As Iterations are

Stories Captured s
Stories Captured om
Roadmap
some reall da
e rea data a
Content
Content
captu re
is in Iteration re
c a p tu
completed and stories
Stories DONE
DONE we better
Useful
Useful
& Relatively Sized
& Relatively Sized Updated ta and iinterin Iteration
nd nterpret
understand our
Software
Software
pret iit
Updated
iin a meani t
product

n a meaningf
ngfull way
u way
Working software
As Roadmap Roadmap
Roadmap provides feedback
content changes
dates are
Dates
Dates on what is
required
updated Updated
Updated

Observe the Progress of Each Iteration
● How many points are completed each iteration?
● On average how many points are usually
completed in an iteration?
● Good estimate of what we are likely to
complete in future iterations
● At the very beginning of a project the
'completion rate' is generally less
● Completion rate typically increases throughout
a project eventually plateauing at about 60%

Observe the Progress of Each Iteration
● How many points are completed each iteration?
● On average how many points are usually
completed in an iteration?
rude but
c rude but
at e s a c
Rate iis are likely to r
on R we a
Complle tiio what rate iindiicato r
Good estimatetof n
Comp e nd c at o
●

complete in risiinglly accu rate
future y accu
ng iterations
surp ris
su rp tiimates
e es t mates
te-a ang e esthe
At the very eriiviing da te-r ang
beginning of r project
for dd er v n g d a
●

for rate' is generally less
'completion
● Completion rate typically increases throughout
a project eventually plateauing at about 60%

Date Ranges From Historical Data
Gradient based on
Completion Rate
Weeks “x Points per Iteration
with Maximum
Iteration Period of y Weeks” Estimated Time

Minimum
Estimated Time

Estimated
Completion Date Range
W1 to W2
Translated to real dates.

Story Points

Date Ranges From Historical Data
Gradient based on
Completion Rate
Weeks “x Points per Iteration
with Maximum
Iteration Period of y Weeks” Estimated Time
Date-Ran
Date-Range
ges are a ve
s are a very
to encaps
to encapsul ry powerful
powerful wa
ulate riisk in
a te r s k i a way y Time
Minimum
n a form su Estimated
form suiitab
for strat
for strateg tablle
e
Estimated egiic pllannin
c p anning
Completion Date Range
W1 to W2
g
Translated to real dates.

Story Points

Don't Forget: Iteration Length
and Feedback

Don't Forget: Iteration Length
and Feedback

viide
o v de
ns p r o
o n s pr
ratiio ck
t e ra t
er I te eedba ck
rt er I F eedba
ho rt
S ho
S
Fa
F ster F
a ster

Use a Tool to help Track Progress
● User Stories are like tickets in an Issue
Tracking System
● Some tools are adapted for Agile Development
like agile-trac (http://www.agile-trac.org)
● At a minimum keep a record of the sizes of all
Stories completed in an iteration
● Records of completed iterations provide raw
data to estimate future iterations
● Tools can automate all of this for you

Good Tools Require Minimal Effort
● Some things have to be done by a human
● For everything else expect your tool to automate it
● For example:
● You must enter User Stories
● You must say which Milestone they belong to and which
Iteration they appear in
● You must say when they are DONE
● The tool should be able to use all that information to
update the Roadmap, expected Completion Dates, allow
Release Notes to be derived and so on

A Quick Lk at agile-trac

Relatively Sized
Relatively Sized
User Stories
User Stories


Relatively Sized
Relatively Sized
User Stories
User Stories Time-boxed
Time-boxed
Iterations
Iterations


Summary
Summary
View with predicted
View with predicted
Completion dates
Completion dates

Relatively Sized
Relatively Sized
User Stories
User Stories Time-boxed
Time-boxed
Iterations
Iterations

Virtual Story-
Virtual Story-
Board
Board

Strategic View is the Roadmap
is the Release Plan
The progress bar
The progress bar
represents the
represents the
relative size of each
relative size of each
Milestone
Milestone

Milestones are
Milestones are
arranged in
arranged in
priority order
priority order

This provides a fast
This provides a fast
Uncompleted
Uncompleted visual comparison of the
visual comparison of the
Milestones have an
Milestones have an relative complexity of
relative complexity of
Expected Completion
Expected Completion each Milestone
each Milestone
Date Range
Date Range

Earliest Expected
Earliest Expected
Date
Date

Latest Expected
Latest Expected
Date
Date

Milestones are Composed of Stories

Completion Stages
Completion Stages
capture a Story's
capture a Story's
Completion Pipeline
Completion Pipeline

Iterations that a
Iterations that a
Story was added to
Story was added to

Iteration pages are Live Plans
Summary View
Summary View
Default wiki pages
Default wiki pages
shows current and
shows current and
associated with
associated with
future iterations
future iterations
the iteration
the iteration

An indication of
An indication of
when the iteration
when the iteration
will end
will end

Overview of the
Overview of the
iteration's
iteration's
progress
progress
Storyboard view
Storyboard view
of the current
of the current
iteration
iteration

Story 'DONE'
Story 'DONE'
status. Either
status. Either
Done or Not Done
Done or Not Done

Iteration History is Maintained

The number of
The number of
points previously
points previously
completed in an
completed in an
iteration
iteration

Questions?

Sttartted butt
S ar ed b u
NOT done
NOT done

Basic Principles of SCM
● There are two sides to tool support
● One is to manage the project life-cycle
● One is to manage the artefacts produced during the
life-cycle
● The two are highly coupled
● You should adopt tools that mirror and exploit
this coupling
● We've briefly looked at the life-cycle tools – now
we'll briefly look at the artefact tools

Use a Source Code Repository
● Chose from one of Subversion, Mecurial or Git
● Subversion is a Centralised Concurrent
Copy-Modify-Write Model
● Mecurial and Git support a Distributed
Concurrent Clone-Modify-Push
Model
● Subversion has the best tool support and will meet
nearly all your needs
● Mecurial and Git are fast becoming the main
alternatives to Subversion – a good string to your
bow

Use a Source Code Repository
● Chose from one of Subversion, Mecurial or Git
● Subversion is a Centralised Concurrent
Copy-Modify-Write Model
support ndersta
Mecurial and Gitme to undDistributednd code
ersta nd code
to u a
Take tiime
●

Concurrent e t
TakClone-Modify-Pushposiitory
r e p os t or y
ent iin a re
age m e n t n a
man agem
Model ma n
● Subversion has the best tool support and will meet
nearly all your needs
● Mecurial and Git are fast becoming the main
alternatives to Subversion – a good string to your
bow

Basic Source Control Etiquette
● Only commit code that builds
● Breaking the Build means that the integrity of the code-
base can no longer be verified
● Regression tests cannot be executed
● Integration with non-breaking code cannot happen
● Commit early and commit often
● Ensures that integration happens early when problems are
smaller
● Always reference a User Story in your Commit
Comment
● Try to limit commits to changes for Single Stories

Basic Source Control Etiquette
● Only commit code that builds
● Breaking the Build means that the integrity of the code-
base can no longer be verified
Earlly
E ar y an
● and Oft
d Often
Regression tests cannot be executed
Imme encodean
non-breaking me ans a happen
me cannot
I
Integration withmm
ediiate s allmos
most
d a te f e
●

fee db
Commit early and commit often dbace ack t
k
●

● Ensures that integration happens early when problems are
smaller
● Always reference a User Story in your Commit
Comment
● Try to limit commits to changes for Single Stories

Branch Only When Essential
● Branching is cheap but merging is expensive
● Branch only for
● Major changes between releases
● High risk or invasive changes that will break the build
● Making fixes to an already released code-base
● To allow breaking changes to be committed without affecting
other developers (usually in a short time)
● Tag often to provide markers for building against, or
branching from, should the need arise
● Prefer a freeze-then-release model to minimise
branching

Branch Only When Essential
● Branching is cheap but merging is expensive
● Branch only for

athe iinst
Major changes between releases
t aga buildt
c t g a ns
●

High risk or invasive changes thatrote c
e yto p will e
o p rotbreak
sollellyreleased code-baseidea
g already t
●

Making fixeshiin g so
Branc h
a nc
to n b a d i d ea
s iis a bad
Br breaking changes subes s a
an
n iis toue committed without affecting
●

iio n ss e
tegrat o in a short time)
In tegrat
● To allow
In
other developers (usually
● Tag often to provide markers for building against, or
branching from, should the need arise
● Prefer a freeze-then-release model to minimise
branching

Test Your Code
● If possible do Test Driven Development
● Tool support can help here
● At a minimum ensure that all core components are tested
● Ensure all components are testable
● Promotes looser coupling between components
● Maintain all your tests as part of your code base
so that they can be executed at any time
● Execute tests as part of your build
● Use a unit test framework for the language you
are working in

Test Your Code
● If possible do Test Driven Development
● Tool support can help here
TDD
TDD
At a minimum ensure that all core components are tested
iis allll a
s a abo
●

q ck an
Ensure alluiic bou are testable
qucomponents t llearni
ut e a
k and va rning fr
●

ng from
d valluabetween components
om
u b e fe
Promotes looser couplingablle
feedba
●

edback
c code base
● Maintain all your tests as part of your k
so that they can be executed at any time
● Execute tests as part of your build
● Use a unit test framework for the language you
are working in

Remember to Refactor!
● You rarely, if ever, get things right the first time
● Not refactoring is essentially discarding
feedback
● A common problem with TDD is that naïve
practitioners omit the refactoring phase
● You want good code that passes tests, not any
code that passes tests

Support Automated Building
● Automated builds rely on tools like Ant, Make
and Scons
● For your language and platform identify and
learn an appropriate tool
● If in doubt Scons works well both for Java and
C++ and uses Python
● Ensure all build files (and scripts) are checked
in as part of your source code

Automate Everything that you can
● Automate the execution of your builds
● Automate the execution of your tests
● Learn one scripting language like Python to help
you with your automation
● The Scons + Python combination is very
powerful as it minimises what you have to learn
● If possible move towards a Continuous
Integration model
● Understand that automation also costs time

Automation is at the heart of Agile
● Automation is one of the key enablers of Agile
Development
● Automation allows a higher return on your effort
and therefore minimises greatly wastage in a
project
● Automation can provide almost instant
feedback on progress allowing you to be more
reactive to changes

Got a Prescription for that?

Almostt finished
Almos finished
butt
bu
NOT done
NOT done

The real world? A Simple Prescription
● Define iterations to be, say 2-3 weeks, starting mid-week
● Take 2-3 weeks to Initiate your project (Iteration 0)
● A list of Relatively Sized User Stories
● A Shared Vision with your stakeholders
● An implicit idea of what you need to do and how you'll do it
● An Architecture on which to build
● Commit to delivering one or more Stories in the First
Iteration (Iteration 1)
● Define what it means for the Stories to be DONE
● Make some notes on how you can verify each Story is DONE
● Include Stories that cover automation and development
environment setup

Continue to Iterate
● Remember you'll have a lot of setup work to do in early
iterations as you learn and adopt new tools
● Focus on making sure you deliver some key functionality each
iteration
● As time passes you'll be able to deliver more as you gain
familiarity with your problem domain and your software
matures
● Make sure you always perform an evaluation of your iteration
so that you have the opportunity to learn and adapt
● Continually update the roadmap and split large stories into
smaller stories are you learn more
● Limit the size of stories in iterations and imminent milestones

And remember!
● You should know the Agile Values and Principles
● Know why you want to do Agile Development
● Understand how an Agile Methodology helps
● Understand that Agile is team focused
● Understand that past progress is used to predict future
progress
● Minimise waste – minimise time spent on work possibly
not required
● Observe and learn from Feedback at all planning levels

What about those birds?

Rulles,,
ack Ru es
eedb ack
lle F eedb
Siimp e F
S mp ea r n ed
L ea r n ed
ed a n d L
r v e d an d
w he n Obse rv
he n Obse werfull
p o w er f u
w e v er y p o
n b e v er y
m,, ca n b
fro m ca
f ro

Questions?

DONE
DONE

ja11sop@agile-trac.org


Feedback Loops in Agile Development

Recommended

More Related Content

What's hot (6)

Viewers also liked (11)

Similar to Feedback Loops in Agile Development (20)

More from AgileOnTheBeach (20)

Recently uploaded (20)

Feedback Loops in Agile Development