Download - Agile planning
![Page 1: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/1.jpg)
Agile Planning
![Page 2: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/2.jpg)
Agenda
Iteration zero and Hardening
Iteration Planning
Release Planning
Agile Planning
Daily Planning
Using Buffers
Predicting velocity
![Page 3: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/3.jpg)
Planning – Why Plan?
Why Plan? Helps in decision making Helps in reducing risks Establishes trust Provides basis for checking progress
![Page 4: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/4.jpg)
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
![Page 5: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/5.jpg)
Planning
![Page 6: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/6.jpg)
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
![Page 7: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/7.jpg)
Waterfall Vs. Iterative development
Is it really 40% done?
End to end Small slices of work 40% done, 100%
valuable
![Page 8: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/8.jpg)
Agile Planning - Planning OnionStrategyPortfolio
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
![Page 9: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/9.jpg)
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.
![Page 10: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/10.jpg)
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
![Page 11: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/11.jpg)
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”
![Page 12: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/12.jpg)
Release Planning – Iteration LengthOne 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
![Page 13: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/13.jpg)
Release Planning – Estimate Velocity
Good to have historic values but as every project & team is unique, these have limited value
Use Historic ValuesIdeal way if feasible. After each iteration the range of possible velocity figures will converge
Run an IterationEstimate 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
![Page 14: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/14.jpg)
Release Planning – Velocity Forecast
Person Hours Available per iteration
Tom 32 – 40
Harry 36 – 40
Rita 20 – 28
Han 16 – 22Total 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
![Page 15: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/15.jpg)
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 HrsDesign 6Code 12Test 8Total 26
Task HrsDesign 10Code 12Test 12Document 10Automate 8Total 52 Task Hrs
Design 10Code 14Test 12Total 36
Task Hrs… …Total 54
Backlog
Effort = 26+52+36 = 114Velocity= 2+5+3=10
![Page 16: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/16.jpg)
Using Velocity for Planning
200 Points
Velocity = 25
200/25 = 8Iterations
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 = 10Iterations
![Page 17: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/17.jpg)
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
![Page 18: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/18.jpg)
Iteration Planning
Iteration PlanningVelocity Driven
Commitment Driven
![Page 19: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/19.jpg)
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”
![Page 20: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/20.jpg)
Commitment Driven - Iteration Planning
Identify iteration goal
Ask for team commitment
Iteration planning done
Remove the story
Select story to addCreate Tasks for story
Estimate Tasks
Adjust Priorities Full
Can CommitNot Full
Can’t Commit
Ref: Mike Cohn’s “Agile Estimation and Planning”
![Page 21: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/21.jpg)
Iteration Zero and Release/Hardening IterationIteration 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.
![Page 22: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/22.jpg)
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
![Page 23: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/23.jpg)
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
![Page 24: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/24.jpg)
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.
![Page 25: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/25.jpg)
Planning BufferMinimal Marketable feature – The smallest set of functionality that when implemented provides value to the customer.
![Page 26: Agile planning](https://reader035.vdocuments.net/reader035/viewer/2022070522/58ee50f31a28ab3c308b45c5/html5/thumbnails/26.jpg)
Thank You