SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
In this presentation, I intend to present the fundamentals, the roles, the processes, the rituals and the values that I believe a team would need to embrace to achieve success down the line in Agile Software Development Management - Product Management, Team Management and Project Management - with the ultimate goal of making planning and forecasting as simple and efficient as it can be.
Why Agile in anyway ?
The problems with Waterfall
Incomplete or moving specifications
Drop of Quality to meet deadlines
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
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)
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.
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
Surprisingly … Scrum leads to way better estimations
Just in Time !
Only implement minimum
requirements, only at the time it is
actually required !
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
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
Product Backlog =
Development tools to organize
work in development team.
Backlog is usually a technical
tool, not a visual management
Very important :
Each and every developer
activity or task should be in the
And linked to a User Story
That is the only possibility to
have reliable planning
Kanban is Flow oriented
Team capacity instead of Sprint capacity
Requires Committees and Teams
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)
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. Principles - Agenda
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
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.
Roles are required to avoid having the whole organization meeting all the
time at every meeting for every possible concern.
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
Roles can be shared. A same co-worker can have multiple roles
Why bother ?
Required Committees and Teams
Identifies product features and requirements
Product Management Committee (X-Weekly)
Designs the Software
Architecture Committee (X-Weekly)
Organizes the Development Sprints
Implements the software
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
What are the priorities
and coming releases
More importantly, when
a specific story will be
available for customers!
estimations when they
have been analyzed by
ARCHCOM and are
sync’ed in Product
The management tool is the story map, not the product backlog (too technical,
The Product Management should be able to decide about priorities using solely the
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 ?
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
A User story is moved to done when all Development Tasks have been
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
Product Kanban Board Maintenance (4/5) – After 1st release
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
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 !
Backlog is synchronized with Story Map
Every task in
backlog should be
kept in sync with a
Story on Story Map
Priorities are kept
in sync as well
1. Specification and Design
Sync between both
worlds is manual
Visual World Digital World
A task will be
All tasks of
AND all tasks
Note : Using
should lead to
How do I know when a story will be delivered ?
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
If one respects all the principles presented previously, such big differences as a on the
chart above should disappear
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
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
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
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
Identification and maintenance of Coding Standards and Architecture Standards
Review of ad’hoc architecture topics
Note : not the same day, that PMC,
a few days after …
Beginning of sprint
Discuss Development Tasks to ensure whole team has a clear view of what needs to be done Detailed
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
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
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
Round table - every team member presents :
Past or current development task
Status on that task and precise progress
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
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
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.
• 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)
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
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)
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)
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
Learning from the field