Agile Planning, Estimation, and Tracking
Agile Planning, Estimation, and Tracking
Syed Rayhan
Co-founder, Code71, Inc.
Contact: [email protected]
Blog: http://blog.syedrayhan.com
Company: http://www.code71.com
Product: http://www.scrumpad.com
Agenda
Section 1
Introduction
Section 2
Planning
Section 3
Estimation
Section 4
Tracking
Section 5
Recap
Section 6
Q&A
www.Code71.com
Copyright 2009 Code71, Inc.
2
www.ScrumPad.com
My Background
Career
Expertise
Interests
www.Code71.com

Co-founder, Code71, Inc., CSP, Agile Coach and Trainer

14+ years of total experience

Co-author of “Enterprise Java with UML”

Iterative incremental development

Technology planning and architecture

On-shore/Off-shore software development using
Agile/Scrum

Cultural aspect of self-organizing team

Scrum for projects delivered remotely

Agile engineering practices
Copyright 2009 Code71, Inc.
3
www.ScrumPad.com
What to Expect
Context

Teams and organizations are adopting Agile/Scrum

Teams struggle with making the transition from waterfall to
Agile/Scrum
Focus
Key
Takeaways
www.Code71.com

Build a base for Agile planning

Contrast Agile planning with Traditional Planning

Address typical questions asked

How to perform sprint planning and estimation

How to perform release planning an estimation

How to track progress against plan

How to adjust plan as project evolves
Copyright 2009 Code71, Inc.
4
www.ScrumPad.com
Agenda
Section 1
Introduction
Section 2
Planning
Section 3
Estimation
Section 4
Tracking
Section 5
Recap
Section 6
Q&A
www.Code71.com
Copyright 2009 Code71, Inc.
5
www.ScrumPad.com
Waterfall Project Planning
Project can be accurately planned in details
“.”
www.Code71.com
Copyright 2009 Code71, Inc.
6
www.ScrumPad.com
In reality, software projects are like…
forecasting weatherrain or shine?
www.Code71.com
Copyright 2009 Code71, Inc.
7
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
8
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
9
www.ScrumPad.com
MoSCoW
Must haves
Minimum Usable SubseT for production
(a.k.a. Minimum Viable Product)
Should haves
Could haves
Would not haves
Important, but absence of it would not make the
product useless
Optional, if fund and time are available
Out of scope, defines the boundary of the product
Pros and Cons?
www.Code71.com
Copyright 2009 Code71, Inc.
10
www.ScrumPad.com
Minimum Viable Product (MVP)
Release#1
R#2
R#3
ideal
Release every sprint
Expanding scope of MVP
www.Code71.com
Copyright 2009 Code71, Inc.
11
www.ScrumPad.com
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?
www.Code71.com
Copyright 2009 Code71, Inc.
12
www.ScrumPad.com
Kano Analysis
Q#1 (Presence of a feature)
Like
Neutral
Dislike
Like
Neutral
Dislike
Q#2 (Absence of a feature)
-
?
L
E
I
?
T
-
L
- disregard, ? probe further, I indifferent
E exciter, L linier, T threshold
www.Code71.com
Copyright 2009 Code71, Inc.
13
www.ScrumPad.com
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?
www.Code71.com
Copyright 2009 Code71, Inc.
14
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
15
www.ScrumPad.com
Sprint Planning
Capacity
Scope
Estimation
• Load factor
• Set a sprint goal
• Task breakdown
• Availability factor
• Take stories from
the top of the
product backlog
• Estimate tasks in
actual hours or days
• Holidays
• Vacations
• Total points =
Velocity
• Assign task owners
• Assign a story owner
• Verify estimate
against capacity
www.Code71.com
Copyright 2009 Code71, Inc.
16
www.ScrumPad.com
Sprint 0
• Project initiation sprint
• Business case
• Environment setup
• Architecture
• Team setup
• Team norms
• Training
www.Code71.com
Copyright 2009 Code71, Inc.
17
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
18
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
19
www.ScrumPad.com
Agenda
Section 1
Introduction
Section 2
Planning
Section 3
Estimation
Section 4
Tracking
Section 5
Recap
Section 6
Q&A
www.Code71.com
Copyright 2009 Code71, Inc.
20
www.ScrumPad.com
Estimation
Relative
Absolute
Story points
Hours/Days
Used for Release planning
Used for Sprint planning
Accuracy is not important
Accuracy is important to some extant
Eliminates bias
Does not eliminate bias
Cannot be compared with
another team’s
Supports comparison
Why relative estimation? Velocity, suitable for longer horizon
www.Code71.com
Copyright 2009 Code71, Inc.
21
www.ScrumPad.com
Relative estimation using “Planning Poker”
Decide on scale
Fibonacci scale
Identify a reference story set
Estimate the rest
Use most understood story as a
reference story for each level on the
scale
Everybody estimates individually, then
reveals as a team, hence the term
“Planning Poker”
Challenges?
www.Code71.com
Copyright 2009 Code71, Inc.
22
www.ScrumPad.com
Definition of “Done”
design review
code review
architecture
load test
functional
design+code+unit test
test
regression
test
www.Code71.com
Copyright 2009 Code71, Inc.
23
www.ScrumPad.com
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?
www.Code71.com
Copyright 2009 Code71, Inc.
24
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
25
www.ScrumPad.com
Velocity
Definition
Points delivered by a team per sprint
How to calculate?
Rolling average of 4 weeks, Max, Min, Lifetime average
Keep in mind
• Velocity without a quality metric is not useful
• Velocity of two teams are not comparable
• Velocity changes with team composition
• Velocity increases with team’s tenure
• Velocity is not productivity
• Do not include bugs and rejected stories
How to use?
• Used to determine sprint scope
• Used to calculate approximate costs of a release
• Used to track release progress
www.Code71.com
Copyright 2009 Code71, Inc.
26
www.ScrumPad.com
Agenda
Section 1
Introduction
Section 2
Planning
Section 3
Estimation
Section 4
Tracking
Section 5
Recap
Section 6
Q&A
www.Code71.com
Copyright 2009 Code71, Inc.
27
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
28
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
29
www.ScrumPad.com
Tracking progress
Daily Scrum
Sprint Review
Retrospective
www.Code71.com
A 15-minute standup meeting where team answers the
following;
tracking
impediments
1) What did I do yesterday?
2) What am I going to work on today?
3) What is impeding my work, if any?
Team meets with the product owner and stakeholders to
show the work done in the current sprint and solicit
feedback.
Team meets at the end of each sprint to discuss1) What is working well?
2) What needs improvement? and
3) How to improve/fix the process?
Copyright 2009 Code71, Inc.
30
www.ScrumPad.com
Burndowns
Track
Remaining
hours
Track done
Daily time entry
• Time spent
• Time remaining
www.Code71.com
Copyright 2009 Code71, Inc.
31
www.ScrumPad.com
Other charts
Tracking
actual time
spent
Tracking
release
www.Code71.com
Copyright 2009 Code71, Inc.
32
www.ScrumPad.com
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?
www.Code71.com
Copyright 2009 Code71, Inc.
33
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
34
www.ScrumPad.com
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
www.Code71.com
Copyright 2009 Code71, Inc.
35
www.ScrumPad.com
Q&A
Contact: [email protected]
Blog: http://blog.syedrayhan.com
Company: http://www.code71.com
Product: http://www.scrumpad.com
www.Code71.com
Copyright 2009 Code71, Inc.
36
www.ScrumPad.com