1. 1
© Jerome Kehrli @ niceideas.ch
https://www.niceideas.ch/roller2/badtrash/entry/agile-planning-tools-and-processes
Agile Planning
An overview of Tools and Processes

2. 2
1. Introduction
2. Fundamentals
2.1 Extreme Programming
2.2 Scrum
2.3 DevOps
2.4 Lean Startup
2.5 Visual Management and Kanban
3. Principles
3.1 Tools
3.2 Organization
3.3 Processes
3.4 Rituals
3.5 Values
4. Overview of whole Process
5. Return on Practices
6. Conclusion
Agenda

3. 3
1. Introduction

4. 4
Why Agile in anyway ?
The problems with Waterfall
Incomplete or moving specifications
Tunnel effect
Drop of Quality to meet deadlines
Agile Manifesto
Individuals and interactions over processes and tools
Working Software over comprehensive documentation
Customer collaboration over Contract negotiation
Responding to changes over following a plan
Some people believes Waterfall is better for planning
But that comes mostly over a lack of mastery of Agility as a whole
At the end of the day, a sound respect to key agile practices work even a lot better
that Traditional Software Development in regards to planning and forecasting
Agile Planning

5. 5
Agilty is a lot of things (1/2)

6. 6
It’s up to every organization to decide and pick up the principles and practices
that make sense to it!
What I will be presenting today is a extended-subset, a derived intersections of
the practices I have sometimes witnessed, sometimes used, sometimes
invented, sometimes heard of in the corporations that have today a good level of
mastering of Agile Planning.
Agilty is a lot of things (2/2)

7. 7
2. Fundamentals

8. 8
Agility down the line …

9. 9
2.1 Extreme Programming

10. 10
eXtreme Programming in a nutshell
Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect
Activities
• Coding
• Testing
• Listening
• Designing
Principles
• Feedback
• Assuming Simplicity
• Embracing changes
Practices
• Pair programming
• Planning Game
• Test-Driven Development
• Continuous Integration
• Refactoring
• Coding Standards
• Collective Code Ownership
• On site customer
• Simple Design
• System metaphor
• Sustainable Pace
• The Planning game
• Boy Scout Rule
• No premature Optimization
• Confirm bugs by failing tests

11. 11
The fundamentals of Agility : XP Practices

12. 12
2.2 Scrum

13. 13
Scrum in a nutshell

14. 14
Waterfall
Workload managed in terms of time
Tests are done by different roles in different phases
Every role estimates the time for his task
 Downfall : work is always late, rush to release, waiting for other people, etc.
Scrum
Whole Scrum team, rather than individuals take the work
Comparing items to each others instead of absolute estimation
Estimation in relative units instead of absolute time : Story Points
Breakdown of stories in as small as possible tasks
Team capacity (OK… Velocity) is based on empirical observation of past sprints
Planning Poker : consensus-based, gamified technique for
estimating effort (relative size) of development goals
force people to think independently and propose their numbers
simultaneously
Surprisingly … Scrum leads to way better estimations
than Waterfall
Story Points

15. 15
2.3 DevOps

16. 16
DevOps principles
Wall of Confusion
Developer Operator

17. 17
DevOps in a nutshell

18. 18
2.4 Lean Startup

19. 19
Lean Startup
(2011)
(2013)
(2011)
(2012)
Alex Osterwalder
Steve Blank
Eric Ries
Ash Maurya
Just in Time !
Only implement minimum
requirements, only at the time it is
actually required !
Measure driven
Each and every implementation is
measurable and measured
Don’t believe, know !
Make measurable predictions !
An action whose effect cannot be
measured is useless.
Speed up development cycles
Deploy and implement all quality practices (XP, Agile,
DevOps) to enable development cycles to be as short as
possible

20. 20
Lean Startup Practices

21. 21
2.5 Visual Management and Kanban

22. 22
(Source : http://alexsibaja.blogspot.ch/2014/08/obeya-war-room-powerful-visual.html)
Toyota

23. 23
Kanban Board
Story Map
Product Backlog
Sprint backlog
Burndown Chart
See product owner video
Visual Management – Relevant Practices

24. 24
A story map is alive !
Constantly challenged, updated, adapted, changed, !
Story Map

25. 25
Story Map Example

26. 26
A real life example

27. 27
Story Map Garbage

28. 28
Product Backlog = Story Map
with more details
Story Map contains stories
Backlog contains Tasks
Both are kept in sync … we’ll
see what are the rituals later
Story Map = Management Tool
: we drive priorities on the Story
Map and adapt priorities of tasks
in Product Backlog on
correspondence
Product Backlog =
Development tools to organize
work in development team.
Backlog is usually a technical
tool, not a visual management
tool
Very important :
Each and every developer
activity or task should be in the
backlog …
And linked to a User Story
 That is the only possibility to
have reliable planning
Product Backlog

29. 29
Kanban is Flow oriented
Team capacity instead of Sprint capacity
Kanban

30. 30
Example of Kanban and Story Maps

31. 31
User Story

32. 32
3. Principles

33. 33
3.1 Tools
3.2 Organization
Required Roles
Requires Committees and Teams
3.3 Processes
From Story Map to product Backlog
Refinement (more details) of tasks
Story maps and Product Backlog are kept in sync
Priorities recovered from Story Map (different_backlogs_priority.png)
Estimation process
Back and force : 2 feedback feeds (story_map_estimations.png & XX)
Development process  SCRUM
Using the Story Map to estimate delivery date (story_map_planing.png)
Note : backlog – since kept in sync to Story Map – should lead to same result !
3.4 Rituals
3.5 Values
3. Principles - Agenda

34. 34
3.1 Tools

35. 35
Product Story Map
Product Management Tool
Visual Tool
Tools to use
Product Kanban Board
Project Management Tool
Visual Tool
Product Backlog
Development Team Management Tool
Digital Tool (not visual)
Jira, Redmine, etc.
Sprint Kanban
Sprint Management Tool
Visual Tool

36. 36
3.2 Organization

37. 37
Team Leader : animates the Team rituals (such as Sprint Planning, Sprint Retrospective, Daily scrum) and
acts as a coach and a mentor to the development team. He is not a manager, he is a leader (Lead by
Example, Management 3.0, etc.). He also represents the development team in other rituals (PMC)
Architect : should be the most experienced developer, the one with the biggest technical and functional
knowledge. Entitled to take architecture decision (refers to the whole team as much as possible) and provides
guidance and support. Responsible to check the Code Quality, sticking to conventions, etc.
Tech Leads and Developers form the core of the development team. Tech Leads are coaches and supports
to developers and represent them in the Architecture Committee
Product Owner : represents the business and drives priorities in good understanding with the market and
customer needs. He is not a leader, he is an arbitrator and acts as the bridge between the business and the
development team.
A must see : https://www.youtube.com/watch?v=vkYEqz_MA5Y
Business representatives : whenever required, business representatives (sales, customers, etc.) have to
be involved in the Product Management Committee by the product Owner whenever required.
Required Roles

38. 38
Efficiency !
Roles are required to avoid having the whole organization meeting all the
time at every meeting for every possible concern.
Focus !
Every role owner should acts as required by his role and put himself in the
right mindset for every ritual. Rituals are eventually a role playing game.
Roles are not functions ! We are not speaking hierarchy here, it’s more a
question of role play : when someone is assigned a role, his objective is to
act and challenge the matters being discussed in correspondence with his
role !
Notes:
Roles can be shared. A same co-worker can have multiple roles
Why bother ?

39. 39
Required Committees and Teams
Identifies product features and requirements
Rituals :
Product Management Committee (X-Weekly)
Designs the Software
Rituals :
Architecture Committee (X-Weekly)
Organizes the Development Sprints
Rituals:
Sprint Planning
Sprint Retrospective
Implements the software
Rituals :
Daily Scrum

40. 40
3.3 Processes

41. 41
From Story Map to Product Backlog

42. 42
Estimations
The Story Map should
contain as up to date
as possible estimations
Again : The story Map
is a management tool
Everyone should be
able to look at it and
understand:
What are the priorities
and coming releases
More importantly, when
a specific story will be
available for customers!
Tasks have
estimations when they
have been analyzed by
ARCHCOM and are
sync’ed in Product
Backlog

43. 43
Initial Estimations
X
13
Y
60
60

44. 44
Refined Estimations
X
Y
68
68
21
1321

45. 45
Final Estimations
X
Y
81
81
34
2134

46. 46
The management tool is the story map, not the product backlog (too technical,
not visual)
The Product Management should be able to decide about priorities using solely the
Story Map
In addition, it should be possible to forecast a delivery date using solely the Story Map
 The Story Map should contains as up to date as possible estimations.
Everyone in the company should be able to take is little calculator, go in front of
the story map and know precisely when a task will be delivered
We’ll see how soon !
Why bother ?

47. 47
Product Kanban Board Maintenance (1/5) - Kanban
TakenInnext
Sprint
Specified,
Design and
Estimated by
ARCHCOM
Finishedand
waitingnext
Deployment
Continuous
Delivery
Acceptance
Tests

48. 48
Product Kanban Board Maintenance (2/5) – 1st Sprint
During the first sprint after this initial stage, the Kanban board in the
middle identifies the Stories that are being worked on and their status
Notes:
A User story is moved to done when all Development Tasks have been
implemented

49. 49
Product Kanban Board Maintenance (3/5) – 2nd Sprint
After first sprint, developed stories are put on the Story Map on the right
and a next set of Stories are being developed

50. 50
Product Kanban Board Maintenance (4/5) – After 1st release
Notes:
Actual releases WILL differ : we can release potentially at every
end of Sprint
The development Team releases at every end of sprint
Consider feature flipping !
Making it a customer release is a Product Management Decision

51. 51
Product Kanban Board Maintenance (5/5) – No releases in done
The Story Map on the right shouldn't have any notion of releases.
It represents the Product as is the current development version and it
makes no sense anymore remembering there which task has been
developed in which release.
Variation: merge after release !

52. 52
Backlog is synchronized with Story Map
Ascendingpriority
Every task in
backlog should be
kept in sync with a
Story on Story Map
Priorities are kept
in sync as well
Synchronized

53. 53
Synchronization Process
1. Specification and Design
2. Estimations
Sync between both
worlds is manual
Visual World Digital World
3. Priorities

54. 54
A task will be
implemented
when
All tasks of
prior releases
are
implemented
AND all tasks
of same
release and
HIGHER
priority are
implemented
Note : Using
the Product
backlog to
estimate
should lead to
same results
since
everything is
in sync
How do I know when a story will be delivered ?

55. 55
Picking-up the extremes makes only little sense : people are sick, leaves on
holidays, some big task gets finished the next sprint, etc
 So we should pick up the second and last-but-one.
This gives us a lower range and an upper range
Using a range addresses uncertainty
Notes
If one respects all the principles presented previously, such big differences as a on the
chart above should disappear
Sprint Velocity


Uncertainty
138
128
Story Points
Sprint

56. 56
Range is used this way:
In case of fixed time, when we
have a fixed delivery date, the
lower and upper values give us the
minimum or maximum set of
features we can have
implemented at that date.
In case of fixed scope, when we
have to release a version of the
software with a given set of
features, the lower and upper
values
Recovering our example, we get:
Using the lower limit of 128 SP per sprint, it would take us 15 sprints to
complete the scope, hence 30 weeks or 6.7 months
Using the upper limit of 138 SP per sprint, it would take us 14 sprints to
complete the scope, hence 28 weeks or 6.2 months
Forecasting
Story Points
Months

57. 57
Development process : SCRUM

58. 58
Sprint Kanban

59. 59
3.4 Rituals

60. 60
Story Mapping
Identification of new needs and requirements (also technical and technological !)
Breakdown of these requirements in User Stories
“Guessing” of an Initial Priority of a User Story based on Value (and foreseen size)
Maintenance (update) of Priorities
Setting of Actual Priorities based on Estimations from Architecture Committee
Review of priorities of Whole Story Map after update of estimations
From Sprint Management Committee
From Development Team
Product Management Committee

61. 61
Specification and Design of User Stories
Specification of functional and non-functional requirements
Identification of business rules
Identification of Acceptance criteria
Design of GUI
Architecture and Design of Software
Estimation of User Stories
Breakdown in individual Development Tasks
This needs to be done sufficiently in advance
Estimation of Development Tasks
Computing of total Estimation and reporting on User Story
Continuous Improvement: understanding of gaps in estimation after notification of Sprint Committee and how
to improve
Software Architecture
Identification and maintenance of Coding Standards and Architecture Standards
Review of ad’hoc architecture topics
Architecture Committee
Note : not the same day, that PMC,
a few days after …

62. 62
Sprint Planning
 Beginning of sprint
Discuss Development Tasks to ensure whole team has a clear view of what needs to be done  Detailed
Tasks
Review and challenge estimations of Detailed Tasks. Update estimation of User Story accordingly.
Feed the Sprint Backlog with such Detailed Tasks until Sprint Capacity is reached
Sprint Retro
 End of Sprint
Review Tasks not completed and create task identifying GAP for next Sprint. Update estimations.
Review SP achieved during sprint and review Sprint Capacity
Discuss issues encountered during Sprint and identify action points. Update processes and rituals accordingly
Continuous Improvement: understanding of gaps in tasks and estimations and how to improve
Sprint Demo
 End of Sprint / really optional with Continuous Delivery and Continuous Acceptance Tests
Present sprint developments and integrate feedback. Create new tasks and update estimations.
Sprint Management Committee

63. 63
Daily scrum
Round table - every team member presents :
Past or current development task
Status on that task and precise progress
Next steps
Next task if former is completed
Identification of unforeseen GAPS and adaptation of estimations
Identification of challenges, issues and support needs
Scheduling of ad’hoc meeting and required attendees to discuss specific issues
Development Team

64. 64
3.5 Values

65. 65
Sticking rituals, respecting principles and enforcing practices is difficult
It’s difficult to ensure and behaves in such a way that breaking the build (failing tests) is
an exception
It’s difficult to respect the boyscout rule
It’s a lot more difficult to design things carefully and stick to the KISS principle
It’s difficult and a lot of work to keep the Story Map and Product Backlog in sync and
up-to-date with the reality.
It’s difficult to stick to the TDD approach
It’s difficult not to squeeze the Kaizen phase at the end of every meeting and being
objective when it comes to analyzing strengths and weaknesses
 It takes discipline and courage
Some help comes from
A strict enforcement of the processes of maintaining them
A strict sticking to the rituals agenda and a sound adaptation of them
Why all these committees / teams / rituals if eventually a person can have several roles ?
Because they enforce discipline : they are scheduled and have precise agendas
 they force the corporation to stick to the processes.
Values

66. 66
4. Overview of whole Process

67. 67

68. 68

69. 69
1

70. 70
2
1

71. 71
2
1

72. 72
2
3
1

73. 73
2
3
1
4

74. 74
2
3
1
4
5

75. 75
2
3
1
4
5
6

76. 76
2
3
1
4
5
6

77. 77
2
3
1
4
5
6
7

78. 78
2
3
1
4
5
6
78

79. 79
2
3
1
4
5
6
78
9

80. 80
2
3
1
4
5
6
78
9
10

81. 81
2
3
1
4
5
6
78
9
10

82. 82
2
3
1
4
5
6
78
9
10
11

83. 83
2
3
1
4
5
6
78
9
10
11
12

84. 84
2
3
1
4
5
6
78
9
10
11
12
13

85. 85
2
3
1
4
5
6
78
9
10
11
12
13
14

86. 86
• Product Management Committee (X-Weekly)
1. Identification of a new User Story
2. Initial foreseen priority (i.e. release) depending on value and initial estimation (oral)
• Architecture Committee (X-Weekly)
3. Design and specification by architecture committee : Story  Development Story  Task
4. Estimation of individual tasks
5. Computation of total SP and setting of size of Development Story and User Story
6. Re-priorization (based on new estimation)
• Sprint Planning + Sprint retrospective (Sprintly)
7. Review of TaskS and discussion : Task  Detailed Task
8. Adaptation of Estimation on TaskS
9. Update of Total Size of Development Story and User Story
10. Notification to Architecture Committee (Kaizen / Sprint retrospective)
• Daily Scrum
11. Identification of Gap on Task
12. Adaptation of Estimation on Task
13. Update of Total Size of Development Story and User Story
14. Notification to Architecture Committee (Kaizen / Sprint retrospective)
Estimation Workflow

87. 87
5. Return on Practice

88. 88
So what practices does it take to achieve reliable planning and forecasting ?

89. 89
Requires

90. 90
Requires

91. 91
Requires

92. 92
Requires

93. 93
Requires

94. 94
Requires

95. 95
Requires

96. 96
Requires

97. 97
Requires

98. 98
Requires

99. 99
6. Conclusion

100. 100
Sprint duration : make it 2 weeks
have potentially at least 2 opportunities to release a month
2 weeks is the best duration to have an accurate Spring Capacity calculation. 1 week is too little. 3 weeks is
too big.
 Hence, continuous delivery is not optional : when releasing every 10 days, one cannot waste any time releasing
(worst case : 3 /10 days for release)
Hence 100% Coverage of branch, lines and features by automated tests is not optional
Each and every developer activity, every day and all day, should be linked to the Story Map
Identified by task which is linked to a User Story
With exceptions … (Meetings, babyfoot, Coffee, etc. Sprint capacity takes them into account)
How to handle support and maintenance ?
Idea : A column on the left of the story map related to maintenance / support
Blocking bug fixes (not urgent !): in next minor release
Non-blocking bug fixes: to be put in next major releases
There is no notion of urgency: bug fixes are blocking or non-blocking, not urgent !
Releases on both Product Backlog and Story Maps are virtual.
They follow an a-priori grouping logic. In practice we can release at every end of sprint => We can release
whenever we are happy with the stories developed in current release.
A good reason for sometimes not versioning releases on Product Backlog and Story Map : simply using Next
minor, next major, long term
Other concerns (1/2)

101. 101
Agile Design
Must have knowledge for the Architecture Team
A Story Map is alive
It is continuously re-prioritized, extended, adapted
Where to put the Story Map + Kanban / Sprint Kanban ?
Should be in a common location where everybody can easily and always see it
Avoid meeting rooms and favor open and public spaces such as the cafeteria
Other concerns (2/2)

102. 102
The method propose here is a recipe
It’s in no way a method to apply blindly, nor rocket science
A specific organization needs to adapt it to what makes sense to it
Remind the Agile Landscape V3 (Chris Webb) …
It forms an alternative to upfront planning and waterfall
Agility : Adapting to change instead of sticking to a plan
Surprisingly (or not !) it leads to more accurate results than traditional planning
Story Points
Learning from the field
Continuous improvement
Conclusion

103. 103
Thanks for listening