Agile Planning
Agenda
Iteration zero and Hardening
Iteration Planning
Release Planning
Agile Planning
Daily Planning
Using Buffers
Predicting velocity
Planning – Why Plan?
Why Plan?
 Helps in decision making
 Helps in reducing risks
 Establishes trust
 Provides basis for checking progress
Planning – Typical Planning Mistakes
 Uncertainty is ignored - Trying to plan too much when too little is known
 Delay in the beginning itself - Too much time and effort goes in planning
 Rigid Plans – trying to fit the work around plan rather than updating plan based on real
time changes
 Plans are activity driven rather than feature
 Incorrect measurement x% complete is not same as x% value
 Parkinson’s law – Work expands to fill the time available
 Activities are often dependent so delay in one cause delay for others
 Features are not developed by Priority
Planning
Agile Planning
 “Planning is everything, plan is nothing”
o Focus on iterative planning rather than trying to plan everything up front and then
trying to stick with initial plan
 Inspect and adapt - Gives a plan that can be changed whenever we learn something new
 Planning happens at every level including product strategy, product roadmap, release
planning and iteration/sprint planning.
 Agile planning is around working product rather than around activities.
It’s better to be roughly right
than precisely wrong.”
John Maynard Keynes
Waterfall Vs. Iterative development
Is it really
40% done?
End to end Small
slices of work 40% done, 100%
valuable
Agile Planning - Planning Onion
Strategy
Portfolio
Product
Release
Iteration
Day
 Organization Level
Strategic planning
 Product selection
inline with org strategy
 Product requirements
met in form of releases.
 Release contains number of
iterations.
 Release planning focused on
identifying and delivering
minimal set of features that will
help to go in market as early as
possible.
 Every day the team plan
how to complete the
highest priority features
and deliver working
software.
Strategy & Portfolio Product
Release
 Short fixed length 1-4 weeks
long timeframes.
 Planning focus here is to
deliver potentially shippable
product in each iteration.
Iteration
Day
Release Planning
 It helps the product owner and the whole team to decide how much must be
developed and how long that will take before they have a releasable product.
 It feeds into strategic planning activities
 Serves as a guidepost towards which project team can progress.
 Two types of plan
 Feature Driven – Scope is fixed. Schedule is flexible.
 Date-Driven – Time is fixed. Scope is flexible.
Release Planning
Inputs Attendees Outputs
 Prioritized product backlog
with Estimates
 Product vision
 Team velocity
 Agenda
 Date (optional)
 Product owner or customer
 Delivery Team(s)
 Agile project manager
 Team Leads (optional)
 Stakeholders (optional)
 Release plan
 Assumptions
 Risks
 Action Items
 Dependencies
 Release backlog
Inputs, attendees, and outputs of a release planning session
Release Planning Steps
Determine
conditions of
Satisfaction
Estimate the
User Stories
Select Stories
and a release
date
Select an
iteration
length
Estimate
Velocity
Prioritize
User
Stories
Do in any
sequence
Ref: Mike Cohn’s “Agile Estimation and Planning”
Release Planning – Iteration Length
One of the key element of release planning is to decide iteration length. Factors in deciding
iteration length:-
 Length of release – Shorter iterations are preferred for shorter releases as that allows
more regular feedback
 Level of uncertainty/Risks – Keep shorter iteration if risk is high
 How long priority can remain unchanged
 The ease of getting feedback
 Overhead of iterating
 Feeling of urgency is maintained
Release Planning – Estimate Velocity
Good to have historic
values but as every project
& team is unique, these
have limited value
Use Historic Values
Ideal way if feasible. After
each iteration the range of
possible velocity figures will
converge
Run an Iteration
Estimate based on team’s
capacity
Make Forecast
Team velocity is needed for release planning to estimate how much can be delivered in every
iteration.
Three options available to calculate team velocity:-
1) Use historical values 2) Run an iteration 3) Make a forecast
Release Planning – Velocity Forecast
Person Hours Available per iteration
Tom 32 – 40
Harry 36 – 40
Rita 20 – 28
Han 16 – 22
Total Hours 104 – 130
Calculate Team’s capacity – An example
 Estimate number of hours effort available based on team size & team members availability.
 Pick few stories, break these into tasks and estimate these. Identify enough stories and tasks to fill the
number of hours available.
 Based on story points of selected stories, velocity can be determined. Instead of using a single value,
it’s better to determine velocity in range.
104 – 130 hrs effort available
Release Planning – Velocity Forecast
Story Story
Points
As user.. Search 2
As admin... Add 5
As visitor .. Inquire 3
As admin .. clone 5
104 – 130 hrs effort available Task Hrs
Design 6
Code 12
Test 8
Total 26
Task Hrs
Design 10
Code 12
Test 12
Document 10
Automate 8
Total 52
Task Hrs
Design 10
Code 14
Test 12
Total 36
Task Hrs
… …
Total 54
Backlog
Effort = 26+52+36 = 114
Velocity= 2+5+3=10
Using Velocity for Planning
200
Points
Velocity
= 25
200/25 = 8
Iterations
Update release plan with some regular frequency. For e.g. if there is any major difference
between velocity assumed initially and actual velocity.
200
Points
Velocity
= 20
200/20 = 10
Iterations
SCRUM – Sprint Planning
 Product Owner presents top priority
stories.
 Clarifications, re-prioritization and
re-estimation
 Selection of stories for iteration.
Iteration Commitment
 Decompose selected stories into task
and create iteration plan
 Estimate tasks in hours
Task Level Planning
Iteration PlanningProduct Backlog
Product Vision
Current Product
Iteration Start &
End Dates
Iteration Goal
Iteration
Backlog
Technology
Team Velocity /
Capacity
Iteration Planning
Iteration Planning
Velocity Driven
Commitment Driven
Velocity Driven - Iteration Planning
Adjust
Priorities
Determine
Target
Velocity
Do in any
sequence
Identify
iteration goal
Select user
Stories
Decompose
user Stories
into Tasks
Estimate
Tasks
Ref: Mike Cohn’s “Agile Estimation and Planning”
Commitment Driven - Iteration Planning
Identify
iteration
goal
Ask for team
commitment
Iteration
planning
done
Remove
the story
Select story
to add
Create
Tasks for
story
Estimate
Tasks
Adjust
Priorities
Full
Can Commit
Not Full
Can’t
Commit
Ref: Mike Cohn’s “Agile Estimation and Planning”
Iteration Zero and Release/Hardening Iteration
Iteration Zero
 Some teams need iteration zero for pre-development work before starting the actual
iterations.
 The kind of activities to be done in iteration zero are:
 Completing third party contracts
 Preparing development environment
 Obtaining Funding
 Organizing any necessary tools such as bug tracker
Hardening / Release Iteration
 Some teams prefer to have hardening / release iteration at the end of release or after
every few iterations.
 Required when team’s definition of done is not sufficient. Hardening means whatever
you need to do to make the system ready for production.
 Shouldn’t be used as dumping ground for sloppy work.
Daily Planning
 Estimation or signing-up for task and keeping relevant artifacts such as task board,
sprint back-log and burn-down charts etc up to date
 Daily Stand-up Meeting
 Time-boxed to 15 minutes
 Same time and same place
 All team members required
 Each team member should respond to 3 questions
 What have you done since the last Daily Scrum regarding this project?
 What will you do between now and the next Daily Scrum meeting
regarding this project?
 What impedes you from performing your work as effectively as possible?
 The key purpose is team coordination and planning on daily basis
 Also, highlights risks and issues
Planning Buffer
 Better to add buffer to your plan to mitigate any uncertainty that can arise in future.
 Buffer is not padding so it is always advisable to communicate buffers to the customer
and reason behind.
 How much buffer needs to be added into plan is depends on historical data and project
complexity.
 Historical data helps in identifying problem hours for each iteration so basically this can
be derived from velocity.
 Types of buffers
 Schedule Buffer
 Feature Buffer
 Budget Buffer
Planning Buffer
 Schedule Buffer
 Generally used for high level planning.
 Two estimates one that gives 50% confidence and other 90%.
 Estimation as range. Work will complete in 4 weeks ± 2 days
 The additional time between 50% to 90% estimate is called as local safety.
 To find overall buffer requirement, a mathematical formula is to do a sum of
squares of differences between 90% and 50% confidence level estimates. Square
root of this sum will be the buffer.
 Feature Buffer
 Many of the agile methodologies recommend that on top of ‘must have’ features,
25-40% additional features should be chosen for the release.
 DSDM also recommends that release shouldn’t have more than 70% ‘must have’
features i.e. 30% ‘should have’ or ‘could have’ features.
Planning Buffer
Minimal Marketable feature – The smallest set of functionality that when
implemented provides value to the customer.
Thank You 

Agile planning

  • 1.
  • 2.
    Agenda Iteration zero andHardening Iteration Planning Release Planning Agile Planning Daily Planning Using Buffers Predicting velocity
  • 3.
    Planning – WhyPlan? Why Plan?  Helps in decision making  Helps in reducing risks  Establishes trust  Provides basis for checking progress
  • 4.
    Planning – TypicalPlanning Mistakes  Uncertainty is ignored - Trying to plan too much when too little is known  Delay in the beginning itself - Too much time and effort goes in planning  Rigid Plans – trying to fit the work around plan rather than updating plan based on real time changes  Plans are activity driven rather than feature  Incorrect measurement x% complete is not same as x% value  Parkinson’s law – Work expands to fill the time available  Activities are often dependent so delay in one cause delay for others  Features are not developed by Priority
  • 5.
  • 6.
    Agile Planning  “Planningis everything, plan is nothing” o Focus on iterative planning rather than trying to plan everything up front and then trying to stick with initial plan  Inspect and adapt - Gives a plan that can be changed whenever we learn something new  Planning happens at every level including product strategy, product roadmap, release planning and iteration/sprint planning.  Agile planning is around working product rather than around activities. It’s better to be roughly right than precisely wrong.” John Maynard Keynes
  • 7.
    Waterfall Vs. Iterativedevelopment Is it really 40% done? End to end Small slices of work 40% done, 100% valuable
  • 8.
    Agile Planning -Planning Onion Strategy Portfolio Product Release Iteration Day  Organization Level Strategic planning  Product selection inline with org strategy  Product requirements met in form of releases.  Release contains number of iterations.  Release planning focused on identifying and delivering minimal set of features that will help to go in market as early as possible.  Every day the team plan how to complete the highest priority features and deliver working software. Strategy & Portfolio Product Release  Short fixed length 1-4 weeks long timeframes.  Planning focus here is to deliver potentially shippable product in each iteration. Iteration Day
  • 9.
    Release Planning  Ithelps the product owner and the whole team to decide how much must be developed and how long that will take before they have a releasable product.  It feeds into strategic planning activities  Serves as a guidepost towards which project team can progress.  Two types of plan  Feature Driven – Scope is fixed. Schedule is flexible.  Date-Driven – Time is fixed. Scope is flexible.
  • 10.
    Release Planning Inputs AttendeesOutputs  Prioritized product backlog with Estimates  Product vision  Team velocity  Agenda  Date (optional)  Product owner or customer  Delivery Team(s)  Agile project manager  Team Leads (optional)  Stakeholders (optional)  Release plan  Assumptions  Risks  Action Items  Dependencies  Release backlog Inputs, attendees, and outputs of a release planning session
  • 11.
    Release Planning Steps Determine conditionsof Satisfaction Estimate the User Stories Select Stories and a release date Select an iteration length Estimate Velocity Prioritize User Stories Do in any sequence Ref: Mike Cohn’s “Agile Estimation and Planning”
  • 12.
    Release Planning –Iteration Length One of the key element of release planning is to decide iteration length. Factors in deciding iteration length:-  Length of release – Shorter iterations are preferred for shorter releases as that allows more regular feedback  Level of uncertainty/Risks – Keep shorter iteration if risk is high  How long priority can remain unchanged  The ease of getting feedback  Overhead of iterating  Feeling of urgency is maintained
  • 13.
    Release Planning –Estimate Velocity Good to have historic values but as every project & team is unique, these have limited value Use Historic Values Ideal way if feasible. After each iteration the range of possible velocity figures will converge Run an Iteration Estimate based on team’s capacity Make Forecast Team velocity is needed for release planning to estimate how much can be delivered in every iteration. Three options available to calculate team velocity:- 1) Use historical values 2) Run an iteration 3) Make a forecast
  • 14.
    Release Planning –Velocity Forecast Person Hours Available per iteration Tom 32 – 40 Harry 36 – 40 Rita 20 – 28 Han 16 – 22 Total Hours 104 – 130 Calculate Team’s capacity – An example  Estimate number of hours effort available based on team size & team members availability.  Pick few stories, break these into tasks and estimate these. Identify enough stories and tasks to fill the number of hours available.  Based on story points of selected stories, velocity can be determined. Instead of using a single value, it’s better to determine velocity in range. 104 – 130 hrs effort available
  • 15.
    Release Planning –Velocity Forecast Story Story Points As user.. Search 2 As admin... Add 5 As visitor .. Inquire 3 As admin .. clone 5 104 – 130 hrs effort available Task Hrs Design 6 Code 12 Test 8 Total 26 Task Hrs Design 10 Code 12 Test 12 Document 10 Automate 8 Total 52 Task Hrs Design 10 Code 14 Test 12 Total 36 Task Hrs … … Total 54 Backlog Effort = 26+52+36 = 114 Velocity= 2+5+3=10
  • 16.
    Using Velocity forPlanning 200 Points Velocity = 25 200/25 = 8 Iterations Update release plan with some regular frequency. For e.g. if there is any major difference between velocity assumed initially and actual velocity. 200 Points Velocity = 20 200/20 = 10 Iterations
  • 17.
    SCRUM – SprintPlanning  Product Owner presents top priority stories.  Clarifications, re-prioritization and re-estimation  Selection of stories for iteration. Iteration Commitment  Decompose selected stories into task and create iteration plan  Estimate tasks in hours Task Level Planning Iteration PlanningProduct Backlog Product Vision Current Product Iteration Start & End Dates Iteration Goal Iteration Backlog Technology Team Velocity / Capacity
  • 18.
  • 19.
    Velocity Driven -Iteration Planning Adjust Priorities Determine Target Velocity Do in any sequence Identify iteration goal Select user Stories Decompose user Stories into Tasks Estimate Tasks Ref: Mike Cohn’s “Agile Estimation and Planning”
  • 20.
    Commitment Driven -Iteration Planning Identify iteration goal Ask for team commitment Iteration planning done Remove the story Select story to add Create Tasks for story Estimate Tasks Adjust Priorities Full Can Commit Not Full Can’t Commit Ref: Mike Cohn’s “Agile Estimation and Planning”
  • 21.
    Iteration Zero andRelease/Hardening Iteration Iteration Zero  Some teams need iteration zero for pre-development work before starting the actual iterations.  The kind of activities to be done in iteration zero are:  Completing third party contracts  Preparing development environment  Obtaining Funding  Organizing any necessary tools such as bug tracker Hardening / Release Iteration  Some teams prefer to have hardening / release iteration at the end of release or after every few iterations.  Required when team’s definition of done is not sufficient. Hardening means whatever you need to do to make the system ready for production.  Shouldn’t be used as dumping ground for sloppy work.
  • 22.
    Daily Planning  Estimationor signing-up for task and keeping relevant artifacts such as task board, sprint back-log and burn-down charts etc up to date  Daily Stand-up Meeting  Time-boxed to 15 minutes  Same time and same place  All team members required  Each team member should respond to 3 questions  What have you done since the last Daily Scrum regarding this project?  What will you do between now and the next Daily Scrum meeting regarding this project?  What impedes you from performing your work as effectively as possible?  The key purpose is team coordination and planning on daily basis  Also, highlights risks and issues
  • 23.
    Planning Buffer  Betterto add buffer to your plan to mitigate any uncertainty that can arise in future.  Buffer is not padding so it is always advisable to communicate buffers to the customer and reason behind.  How much buffer needs to be added into plan is depends on historical data and project complexity.  Historical data helps in identifying problem hours for each iteration so basically this can be derived from velocity.  Types of buffers  Schedule Buffer  Feature Buffer  Budget Buffer
  • 24.
    Planning Buffer  ScheduleBuffer  Generally used for high level planning.  Two estimates one that gives 50% confidence and other 90%.  Estimation as range. Work will complete in 4 weeks ± 2 days  The additional time between 50% to 90% estimate is called as local safety.  To find overall buffer requirement, a mathematical formula is to do a sum of squares of differences between 90% and 50% confidence level estimates. Square root of this sum will be the buffer.  Feature Buffer  Many of the agile methodologies recommend that on top of ‘must have’ features, 25-40% additional features should be chosen for the release.  DSDM also recommends that release shouldn’t have more than 70% ‘must have’ features i.e. 30% ‘should have’ or ‘could have’ features.
  • 25.
    Planning Buffer Minimal Marketablefeature – The smallest set of functionality that when implemented provides value to the customer.
  • 26.