Agile Planning, Estimation, and Tracking

Agile Planning, Estimation, and Tracking
Agile Planning, Estimation, and Tracking
Syed Rayhan
Co-founder, Code71, Inc.
Contact: srayhan@code71.com
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
Copyright 2009 Code71, Inc.

www.Code71.com www.ScrumPad.com
2
My Background
Co-founder, Code71, Inc., CSP, Agile Coach and Trainer
14+ years of total experience
Career
Co-author of Enterprise Java with UML
Iterative incremental development
Technology planning and architecture

Expertise
On-shore/Off-shore software development using
Agile/Scrum
Cultural aspect of self-organizing team

Scrum for projects delivered remotely
Interests
Agile engineering practices

3
What to Expect
Teams and organizations are adopting Agile/Scrum
Context
Teams struggle with making the transition from waterfall to
Agile/Scrum
Build a base for Agile planning
Contrast Agile planning with Traditional Planning

Focus
Address typical questions asked
How to perform sprint planning and estimation

How to perform release planning an estimation
Key
How to track progress against plan
Takeaways
How to adjust plan as project evolves

4
Agenda
Section 2 Planning
Section 4 Tracking
Section 5 Recap
Section 6 Q&A

5
Waterfall Project Planning
Project can be accurately planned in details

6
In reality, software projects are like
forecasting weather-
rain or shine?

7
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 Critical path is important

boxing
Planning becomes a prioritization exercise

8
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

9
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?

10
Minimum Viable Product (MVP)
Release#1 R#2 R#3
ideal
Release every sprint
Expanding scope of MVP

11
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?

12
Kano Analysis
Q#1 (Presence of a feature)
Like Neutral Dislike
- ? L
Like
Q#2 (Absence of a feature)
Neutral
E I ?
Dislike
L T -
- disregard, ? probe further, I indifferent

E exciter, L linier, T threshold

13
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?
14
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

15
Sprint Planning
Capacity Scope Estimation
Load factor Set a sprint goal Task breakdown

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

16
Sprint 0
Project initiation sprint

Business case
Environment setup
Architecture
Team setup
Team norms
Training

17
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

18
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

19
Agenda
Section 2 Planning
Section 4 Tracking
Section 5 Recap
Section 6 Q&A

20
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 Supports comparison

another teams
Why relative estimation? Velocity, suitable for longer horizon

21
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?

22
Definition of Done
design review code review

architecture load test
design+code+unit test functional
test
regression
test

23
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 To err on the side of caution

highest
Pros and Cons?

24
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

25
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
Keep in mind Velocity changes with team composition
Velocity increases with teams 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

26
Agenda
Section 2 Planning
Section 4 Tracking
Section 5 Recap
Section 6 Q&A

27
How do you track progress?
MS Project
50% done
Waterfall
Vs. ScrumPad
3 stories done, 5 stories remaining

Agile
You dont get credit for partial work

28
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

29
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?

30
Burndowns
Track
Remaining
hours
Track done
Daily time entry

Time spent
Time remaining

31
Other charts
Tracking
actual time
spent
Tracking
release

32
Lets 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?

33
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
34
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

35
Q&A
Contact: srayhan@code71.com
Blog: http://blog.syedrayhan.com
Company: http://www.code71.com
Product: http://www.scrumpad.com

36

Agile Planning, Estimation, and Tracking

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Planning, Estimation, and Tracking

Uploaded by

Copyright:

Available Formats

Agile Planning, Estimation, and Tracking

Agile Planning, Estimation, and Tracking

Copyright 2009 Code71, Inc.

Iterative incremental development

Technology planning and architecture

Cultural aspect of self-organizing team

Copyright 2009 Code71, Inc.

Build a base for Agile planning

Contrast Agile planning with Traditional Planning

How to perform sprint planning and estimation

Copyright 2009 Code71, Inc.

Copyright 2009 Code71, Inc.

Project can be accurately planned in details

Copyright 2009 Code71, Inc.

Copyright 2009 Code71, Inc.

Iterative, incremental All or none

Prioritization is key activity of planning Prioritization is not important

Critical path is eliminated through time Critical path is important

Planning becomes a prioritization exercise

Copyright 2009 Code71, Inc.

Informal Ad-hoc and intuitive

Formal Priority = Business Value/Complexity

ROI (= Business value Cost) based prioritization

Kano Mandatory, Linear, Exciter

Copyright 2009 Code71, Inc.

Must haves Minimum Usable SubseT for production

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

Could haves Optional, if fund and time are available

Pros and Cons?

Copyright 2009 Code71, Inc.

Release#1 R#2 R#3

Copyright 2009 Code71, Inc.

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

Additional Question for trade-off analysis

Copyright 2009 Code71, Inc.

- disregard, ? probe further, I indifferent

Copyright 2009 Code71, Inc.

Set a release goal

Copyright 2009 Code71, Inc.

Capacity Scope Estimation

Load factor Set a sprint goal Task breakdown

Copyright 2009 Code71, Inc.

Project initiation sprint

Copyright 2009 Code71, Inc.

One or more sprints needed to stabilize a release before

Copyright 2009 Code71, Inc.

A team size of 7-9

Copyright 2009 Code71, Inc.

Copyright 2009 Code71, Inc.

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 Supports comparison

Why relative estimation? Velocity, suitable for longer horizon

Copyright 2009 Code71, Inc.

Decide on scale Fibonacci scale

Identify a reference story set Use most understood story as a

Everybody estimates individually, then

Copyright 2009 Code71, Inc.

design review code review

Copyright 2009 Code71, Inc.

Consensus Ask the outliers and discuss as a team to