1. Feedback Loops in Agile
Development
from the basic concepts to a prescriptive start
Jamie Allsop
http://www.agile-trac.org

2. 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
http://www.agile-trac.org

3. 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

4. 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

5. 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

6. 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”

7. 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 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
● Emphasis on where we would like to be: not where we are,
or where we could be. Basically “wishful planning”

8. 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
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
●
● Emphasis on where we would like to be: not where we are,
or where we could be. Basically “wishful planning”

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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...

15. 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...

16. Agile Development is Value Driven

17. Agile Development is Value Driven
30% Complete
T3
T2
T1

18. Agile Development is Value Driven
30% Complete
S1 S2 S3
T3
T2
T1

19. Agile Development is Value Driven
30% Complete
Little or No User Value
Task to Value Correlation Low
S1 S2 S3
T3
T2
T1

20. Agile Development is Value Driven
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

21. Agile Development is Value Driven
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

22. Where to begin...?

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

24. 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

25. Let's try again
Point your browser to
http://agilemanifesto.org/

26. The Agile Value System

27. 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

28. We All Need Principles
● F ee
F
Early and continuous ack
dbac k
eedbdelivery 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

29. We All Need Principles
● F ee
F
Early and continuous ack
dbac k
eedbdelivery of valuable software
k
● eedbac k
F ee dbac
Welcome changing requirements
F
● 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

30. We All Need Principles
● F ee
F
Early and continuous ack
dbac k
eedbdelivery of valuable software
k
● eedbac k
F ee dbac
Welcome changing requirements
F k
● F eedbac k
Deliver working software frequentlyee
F dbac
● 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

31. We All Need Principles
● F ee
F
Early and continuous ack
dbac k
eedbdelivery of valuable software
k
● eedbac k
F ee dbac
Welcome changing requirements
F k
F eedbac k
Deliver working software frequentlyee
F dbac
back
●
●
eedbac k
Business people and developers work together d
F ee
F
● 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

32. We All Need Principles
● F ee
F
Early and continuous ack
dbac k
eedbdelivery of valuable software
k
● eedbac k
F ee dbac
Welcome changing requirements
F k
F eedbac k
Deliver working software frequentlyee
F dbac
back
●
●
eedbac k
Business people and developers work together d
F ee
F
● Trust motivated individuals
ck
● Feedba ck
Fe
Working software is the primary measure of progress edba
● 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

33. We All Need Principles
● F ee
F
Early and continuous ack
dbac k
eedbdelivery of valuable software
k
● eedbac k
F ee dbac
Welcome changing requirements
F k
F eedbac k
Deliver working software frequentlyee
F dbac
back
●
●
eedbac k
Business people and developers work together d
F ee
F
● Trust motivated individuals
ck
● Feedba ck
Fe
Working software is the primary measure of progress edba
● Promote sustainable development
● Technical excellence and good design
● Simplicity is essential
● Self-organising teams
k
● F eedbac k
Team reflection and adjustment ee
F dbac
● Face to Face Communication is the most effective

34. We All Need Principles
● F ee
F
Early and continuous ack
dbac k
eedbdelivery of valuable software
k
● eedbac k
F ee dbac
Welcome changing requirements
F k
F eedbac k
Deliver working software frequentlyee
F dbac
back
●
●
eedbac k
Business people and developers work together d
F ee
F
● Trust motivated individuals
ck
● Feedba ck
Fe
Working software is the primary measure of progress edba
● Promote sustainable development
● Technical excellence and good design
● Simplicity is essential
● Self-organising teams
k
● F eedbac k
Team reflection and adjustment ee
F dbac
● Face to Face Communication is the mosteedback
F eedback
effective
F

35. 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

36. 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

37. Agile Development in a Nutshell

38. Agile Development in a Nutshell
START
Incubation
Incubation

39. Agile Development in a Nutshell
START
Incubation
Incubation
Initiation
Initiation

40. Agile Development in a Nutshell
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

41. Agile Development in a Nutshell
START
Incubation
Incubation
Initiation
Initiation
User Stories
Story 12
Story 2
Story 1 Story 17 Story 13
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

42. Agile Development in a Nutshell
START
Incubation
Incubation
Initiation
Initiation
Tacit
Knowledge User Stories
Story 12
Story 2
Story 1 Story 17 Story 13
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

43. Agile Development in a Nutshell
START
Incubation
Incubation
Initiation
Initiation
Tacit
Knowledge User Stories
Story 12
Story 2
Story 1 Story 17 Story 13
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

44. Agile Development in a Nutshell
START
Incubation
Incubation
Initiation
Initiation
Tacit Shared
Knowledge User Stories Vision
Story 12
Story 2
Story 1 Story 17 Story 13
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

45. Agile Development in a Nutshell
START
Incubation
Incubation
Initiation
Initiation
Tacit Shared
Knowledge User Stories Vision
Story 12
Story 2
Story 1 Story 17 Story 13
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

46. Agile Development in a Nutshell
START
Incubation
Incubation
User Stories
Iteration Planning
Iteration Planning
Initiation
Initiation
Tacit Shared
Knowledge User Stories Vision
Story 12
Story 2
Story 1 Story 17 Story 13
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

47. Agile Development in a Nutshell
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
Knowledge User Stories Vision
Story 12
Story 2
Story 1 Story 17 Story 13
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

48. Agile Development in a Nutshell
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
Knowledge User Stories Vision
Working Software
Story 2
Story 12
& Documentation
Story 1 Story 17 Story 13
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

49. Agile Development in a Nutshell
START Iteration Development
Iteration Development
Incubation
Incubation Tacit
User Stories Knowledge 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
Knowledge User Stories Vision
Working Software
Story 2
Story 12
& Documentation
Story 1 Story 17 Story 13
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

50. Agile Development in a Nutshell
START Iteration Development
Iteration Development
Incubation
Incubation Tacit
User Stories Knowledge 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
Knowledge User Stories Vision
Working Software
Story 2
Story 12
& Documentation
Story 1 Story 17 Story 13
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

51. Agile Development in a Nutshell
START Iteration Development
Iteration Development
Incubation
Incubation Tacit
User Stories Knowledge 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
Knowledge User Stories Vision
Working Software
Story 2
Story 12
& Documentation
Story 1 Story 17 Story 13
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
Iteration Retrospective
Story 24
Story 20
M1 M2 M3 Mn

52. Agile Development in a Nutshell
START Iteration Development
Iteration Development
Incubation
Incubation Tacit
User Stories Knowledge 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
Knowledge User Stories Vision
Working Software
Story 2
Story 12
& Documentation
Story 1 Story 17 Story 13
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
Iteration Retrospective
Story 24
Story 20
Ownership
M1 M2 M3 Mn
Evolution

53. Agile Development in a Nutshell
START Iteration Development
Iteration Development
Incubation
Incubation Tacit
User Stories Knowledge 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
Knowledge User Stories Vision
Working Software
Story 12
& Documentation
Story 2
Issues
Issues POs
Story 1 Story 17 Story 13
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
Iteration Retrospective
Iteration Retrospective
Story 24
Story 20
Ownership
M1 M2 M3 Mn
Evolution

54. Agile Development in a Nutshell
START Iteration Development
Iteration Development
Incubation
Incubation Tacit
User Stories Knowledge 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
Knowledge User Stories Vision
Working Software
Story 12
& Documentation
Story 2
Issues
Issues POs
Story 1 Story 17 Story 13
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
Iteration Retrospective
Iteration Retrospective
Story 24
Story 20
Shared
Vision Ownership
M1 M2 M3 Mn
Evolution

55. Agile Development in a Nutshell
START ITERATE Iteration Development
Iteration Development
Incubation
Incubation Tacit
User Stories Knowledge 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
Knowledge User Stories Vision
Working Software
Story 12
& Documentation
Story 2
Issues
Issues POs
Story 1 Story 17 Story 13
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
Iteration Retrospective
Iteration Retrospective
Story 24
Story 20
Shared
Vision Ownership
M1 M2 M3 Mn
Evolution

56. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
Time

57. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time

58. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time

59. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time

60. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time
Release at end
of Iteration Internal
External
Release x

61. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time
Release at end
of Iteration Internal Milestone A
External
Release x Release x+1

62. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time
Release at end
of Iteration Internal Milestone A
External
Release x Release x+1 Release x+2

63. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time
Release at end
of Iteration Internal Milestone A
External
Release x Release x+1 Release x+2
Release at end Milestone A
of Milestone Internal
External

64. Milestones, Iterations & Releases
Milestone A Milestone B
Iteration x Iteration x+1 Iteration x+2
User Stories
Completed
Over Time
Time
Release at end
of Iteration Internal Milestone A
External
Release x Release x+1 Release x+2
Release at end Milestone A
of Milestone Internal
External
Release A?

65. Milestones, Iterations & Releases
● 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

66. Milestones, Iterations & Releases
● 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

67. 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.

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

69. 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

70. User Story Dependency View
Implicit Implementation Ordering
● The flatter this view the more flexible the release planning
Dependency View of User Stories
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

71. 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 ...

72. 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 ...

73. 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

74. 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 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

75. 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 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

76. 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
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

77. 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

78. 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

79. Understand Different Levels of Planning

80. Understand Different Levels of Planning
Strategy

81. Understand Different Levels of Planning
Strategy
Portfolio

82. Understand Different Levels of Planning
Product is composed of Releases
Strategy
Portfolio
Product

83. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1
Strategy
Portfolio
Product
Release

84. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0
Strategy
Portfolio
Product
Release

85. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
Strategy
Portfolio
Product
Release

86. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
Strategy
Portfolio
Product
Release
Iteration 1

87. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
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

88. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
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
Automate Tests 2 days

89. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
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
Automate Tests 2 days

90. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
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
Automate Tests 2 days

91. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
Strategy
Portfolio
Product
Release
Iteration 1 Iteration 2 Iteration 3 Iteration 4
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 ...
Automate Tests 2 days

92. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
Strategy
Portfolio
Product
Release
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Iteration
Task Time Daily
Design X 1 hour Story Active Done
½ t?
Implement X day
midays
OpsUser ...
?
m4 ues
Implement Y
an
Co SysAdmin ... I ss
MeetingsC 1 hour Any
Trader ...
Automate Tests 2 days

93. Understand Different Levels of Planning
Product is composed of Releases
Milestone 1 Milestone 2 is Release 1.0 Milestone 3
Strategy
Portfolio
Product
Release
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Iteration
Task Time Daily
Design X 1 hour Story Active Done
½ 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

94. 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

95. Splitting Stories as an Example
Large Story
Not Well Understood

96. Splitting Stories as an Example
Large Story Split Large Story to
Not Well Understood Smaller Stories

97. Splitting Stories as an Example
Large Story Split Large Story to
Not Well Understood Smaller Stories

98. Splitting Stories as an Example
?
Large Story Split Large Story to
Not Well Understood Smaller Stories

99. Splitting Stories as an Example
?
Rescoping Improves
Understanding
Large Story Split Large Story to
Not Well Understood Smaller Stories

100. Splitting Stories as an Example
?
Rescoping Improves
Understanding
Large Story Split Large Story to
Not Well Understood Smaller Stories
Refinement Improves
Understanding

101. 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