Agile Network India | Meetup | Agile Planning - A value driven approach | Udayakiran Joshi

- Udaykiran Joshi
Agile Planning
A value driven delivery approach

Agile Planning – A value driven delivery 2
• Traditional planning vs Agile planning
• Common myths about planning in Agile
• Levels of Agile Planning
• Techniques for Agile Planning & Estimations
• Velocity Demystified
• Why Agile planning and estimations can go wrong?
Topics:

The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaborationover contract negotiation
Responding to changeover following a plan
While there is value in the items on the right, we value the items on the left more.

Principles behind Agile Manifesto
Source: http://agilemanifesto.org/principles.html
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.

Principles behind Agile Manifesto
Source: http://agilemanifesto.org/principles.html
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances
agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-
organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Traditional Vs Agile Planning
Plan Driven Approach Value Driven Approach
The goal is to finish the tasks The goal is to deliver business value
Silo mindset – Analysis, Design ,
Development can happen independently
Collaborative mindset
Follow the plan - always PDCA (Plan, Do, Check & Act)
Uses defined process control model Uses empirical process control model
Spends lots of time planning upfront
Planning at multiple levels – Just enough
planning at each level
Coordinate and control Inspect & adapt
Deliver value only at the end – everything at
once
Deliver value at each stage – Highest value
features (MVPs) first

Traditional Vs Agile Planning
 “A good plan is one that stakeholders find sufficiently reliable that they can use it
as the basis for making decisions.” – Mike Cohn
 “Everyone has a plan until they get punched in the mouth.” – Mike Tyson
 The idea is to continuously make adjustments (re-estimate) based on the real
data once it becomes available.
 80/20 Rule – 80% the value in 20% of the features – maximize the amount of work
not done!
 “Work expands so as to fill the time available for completion”. – Parkinson’s law
 The amount of time that one has to perform a task is the amount of time it will
take to complete the task.

Common myths about planning in Agile
Myth: Agile teams should accommodate the changes all the time! Manifesto
says – “Responding to Change”. So teams can’t say ‘NO’ to changing
requirements!
Truth: Agile teams welcome changes even in the late stages of the project.
However don’t encourage changes within the ‘Sprint’ box!
 Factors impacting Selection of Sprint Lengths:
 The amount of uncertainty
 How long priorities can remain unchanged
 The ease & necessity of getting feedback
 The overhead of iterating
 How soon a sense of urgency needs to be established

Common myths about planning in Agile
Myth: Agile teams don’t plan much / Agile means no planning – Just Do It!
Truth: Agile teams plan more and plan at multi-levels based on continuous
feedback at every stage.
 Multi Level Agile Planning:
 Product Vision
 Product Roadmap
 Release planning
 Sprint Planning
 Daily planning

Levels of Agile Planning

Techniques for Agile Planning & Estimations
• Estimations in Size Vs Time
• Relative Vs Absolute estimations
• Triangulation
• Fibonacci series
• Planning Poker
“It’s better to be roughly right than precisely wrong.” - John Maynard Keynes

‘Velocity’ Demystified!
 A key tenet of agile estimation is we estimate size and derive
duration!
 To derive duration – use Velocity
 Velocity – Avg number of story points completed/sprint/team
 It takes at least 2-3 sprints to get a gauge of Velocity
 The primary use of Velocity is to predict the release timelines
 Velocity can give strong insights regarding team stability and
help team inspect
 Velocity assists in Sprint planning but can’t be the sole criteria

‘Velocity’ Demystified!
Factors that impact Velocity:
 Unstable teams (members keep changing)
 Lack of dedicated Team members
 Unavailability of healthy backlog
 Lack of Full-stack or T-shaped developers
 Multiple dependency on other teams
 Poorly defined DoD (Definition of Done)
Velocity can’t be and shouldn’t be used as a productivity
measure for a team or an individual!

Why Agile planning and estimations can go wrong?
 Team members are not T-shaped and don’t consider DoD for
pointing.
 Lack of solid DoD – Team move forward with lot of Technical Debt
 Component based teams instead of Cross-functional teams
Stories are split incorrectly – Lack of swarming
 Tendency to change a story point based on the actual effort or
when more info received
 Estimates are often misused against programmers and push them
to work faster or over burn! This leads to unhappy programmers and
poor quality.

Release Burndown charts

Sources & Additional reading
• www.mountaingoatsoftware.com (Mike Cohn)
• Mindset behind agile planning (pmi.org)
• Agile Estimating and Planning by Mike Cohn
• Agile Project Management with Scrum by Ken Schwaber

Agile Network India | Meetup | Agile Planning - A value driven approach | Udayakiran Joshi

More Related Content

What's hot (20)

Similar to Agile Network India | Meetup | Agile Planning - A value driven approach | Udayakiran Joshi (20)

More from AgileNetwork (20)

Recently uploaded (20)

Agile Network India | Meetup | Agile Planning - A value driven approach | Udayakiran Joshi