Agile

Estimation and Planning

 Agile Approach

• Individuals and interactions

• Working Software
• Customer collaboration
• Adaptation to change is more important than following the initial plan

---x---
Plans are nothing; planning is everything
Eisenhower
Agile projects successful 3X more than non-
agile projects.
 Benefit of (good) Estimates

• Reduce risk

• Reduce uncertainty

• Help in decision making

• Establishes trust

• Transmit information/knowledge
 Planning

Agile Waterfall

Empirical Predictive

Iterative, incremental All or none

Prioritization is key activity of planning Prioritization is not important

Critical path is eliminated through time boxing Critical path is important

Planning becomes a prioritization exercise

 How to do prioritization?

Informal Ad-hoc and intuitive

MoSCoW Must have, Should have, Could have, Would not have

Formal Priority = Business Value/Complexity

ROI (= Business value – Cost) based prioritization

Kano Mandatory, Linear, Exciter

Threshold, Performance, Excitement
 MoSCoW

Must haves Minimum Usable SubseT for production (a.k.a.

Minimum Viable Product)

Should haves Important, but absence of it would not make the product
useless

Could haves Optional, if fund and time are available

Would not haves Out of scope, defines the boundary of the product

Pros and Cons?

 Minimum Viable Product (MVP)

Release#1 R#2 R#3

ideal
Release every sprint
Expanding scope of MVP
 Kano Analysis

Survey

Q#1 Rate your satisfaction if the product has “this” feature?

Q#2 Rate your satisfaction if the product does not have “this” feature?

Answers:
A) Like it,
B) Neutral,
C) Dislike it

Additional Question for trade-off analysis

How much extra would you pay for “this” or more of “this” feature?
 Kano Analysis
Q#1 (Presence of a feature)
Like Neutral Dislike
Like

- ?
Q#2 (Absence of a feature)

L
Neutral

E I ?
Dislike

L T -

- disregard, ? probe further, I indifferent

E exciter, L linier, T threshold
 Formal
BV Complexity Priority
High Low 1

High Medium 2

High High 3?
Medium Low 4?

Low Low 5?

Medium Medium 6?

Medium High 7

Low Medium 8

Low High 9

Pros and Cons?

 Release Planning
• Set a release goal
• Determine scope through prioritization
• Determine a release date
• Define sprints
• Allocate stories to sprints
• Product backlog grooming
• Ideally release every sprint

12
 Sprint Planning

Capacity Scope Estimation

• Load factor • Set a sprint goal • Task breakdown

• Availability factor • Take stories from the • Estimate tasks in actual
• Holidays top of the product hours or days
backlog • Assign task owners
• Vacations
• Total points =
• Assign a story owner
Velocity
• Verify estimate against
capacity

13
 Sprint 0

• Project initiation sprint

• Business case
• Environment setup
• Architecture
• Team setup
• Team norms
• Training

14
 Integration / Stabilization Sprint

• One or more sprints needed to stabilize a release before final

rollout
• Ideally a product is always ready for rollout
• Final integration and regression tests
• Load test
• Any last minute bug fixes
• Production environment setup
• Any other steps (organization specific) needed before production
rollout

15
 Rules of thumb
• A team size of 7-9
• 1 and half medium stories per developer
• 1 Tester for every two developers
• Do not change sprint length
• Prefer 100% allocation over partial allocation of people
 Estimation
Relative Absolute

Story points Hours/Days

Used for Release planning Used for Sprint planning

Accuracy is important to some

Accuracy is not important extant

Eliminates bias Does not eliminate bias

Cannot be compared with Supports comparison

another team’s

Why relative estimation? Velocity, suitable for longer horizon

 Relative estimation using “Planning Poker”

Decide on scale Fibonacci scale

Identify a reference story set Use most understood story as a reference

story for each level on the scale

Everybody estimates individually, then

Estimate the rest reveals as a team, hence the term “Planning
Poker”

Challenges?
 Definition of “Done”

design review code review

architecture load test
design+code+unit test functional
test
regression
test
 How to resolve disagreement in estimation?

Consensus Ask the outliers and discuss as a team to agree on

an estimate

Majority Pick the one that was chosen by the majority

Choose the highest To err on the side of caution

Pros and Cons?

 Rules of thumb

• Tasks should be 4 -16 hours

• For a two-week sprint (most popular sprint length)
• 2-4 hours planning
• 1-2 hours of sprint review
• 1-2 hours of sprint retrospective
• Allocate a fixed hours for production support or other unavoidable routine work (10-
15%)
• 10% for product backlog grooming
 Velocity

Definition Points delivered by a team per sprint

How to calculate? Rolling average of 4 weeks, Max, Min, Lifetime average

• Velocity without a quality metric is not useful

• Velocity of two teams are not comparable
• Velocity changes with team composition
Keep in mind
• Velocity increases with team’s tenure
• Velocity is not productivity
• Do not include bugs and rejected stories

• Used to determine sprint scope

How to use? • Used to calculate approximate costs of a release
• Used to track release progress
 How do you track progress?

MS Project

50% done
Waterfall

Vs. ScrumPad

3 stories done, 5 stories remaining

Agile

You don’t get credit for partial work

 Tracking progress

Sprint Burndown Track remaining hours, track done/remaining points by day

Release Burndown Track remaining points by sprint

Sprint Burnup Track time spent by day

Metrics Velocity,
Bug find rate per sprint,
Bug fix rate per sprint,
Test coverage
 Tracking progress

Daily Scrum A 15-minute standup meeting where team answers the

following; tracking
1) What did I do yesterday? impediments
2) What am I going to work on today?
3) What is impeding my work, if any?

Sprint Review Team meets with the product owner and stakeholders to show
the work done in the current sprint and solicit feedback.

Retrospective Team meets at the end of each sprint to discuss-

1) What is working well?
2) What needs improvement? and
3) How to improve/fix the process?
 Burndowns
Track
Remaining
hours

Track done

Daily time entry

• Time spent
• Time remaining
Other charts
Tracking actual
time spent

Tracking
release
 Let’s test our understanding
 Difference between relative vs. absolute estimation?
 How to do resource allocation?
 How to handle shared resources?
 How to plan for production support work?
 Do you still need a Gantt chart?
 How to plan for fixed bid contract?
 Who does planning?
 What is velocity?
 How to improve estimation?
 How do you ensure team delivers what they plan to deliver in a sprint?
 Recap
• Prioritize product backlog on an on-going basis

• Estimate backlog in story points for release planning

• Estimate backlog in actual hours or days for sprint planning

• Pick a suitable sprint length and stick with it

• Allocate people to a single project in a single sprint

• Staff the team in the beginning and keep the team in place through out the life of the
project
 Recap contd.
• The team should be cross-functional- include testers, Sys admins, DBA,
SMEs

• Team should be physically or virtually collocated

• Know your team “velocity”

• Use open space

• Use appropriate information radiators

Q&A

32