Points vs. Hours - inspired by a discussion on LinkedIn. Presented at NWA PMI Chapter Meeting October 16, 2017.

1. Agile Estimation
Inspired by conversations on LinkedIn
Martin R. Bailey PMP, ACP, CSM

2.  Recently there have been several
conversations on LinkedIn about Agile
estimations.
 This may have been prompted by those new
to Agile, or a push for discussions by Purists.
 I am addressing this discussion hoping to add
clarification

3.  Agile is based more on Product results
◦ Normally not Project
◦ May include multiple releases
◦ May include continuous improvement
 Agile work may also have deadlines
◦ Seasonal
◦ Market schedule
◦ Class Semesters

4. Hours Points
 Time is a definite and
internationally agreed
upon measurement
 Time can be expressed
in hours, weeks,
months, and years
 Agile uses Sprints as
increments of Time
 Points are used as an
arbitrary estimate of
effort
 Scrum Teams are
expected to have their
own value of points
 Point values for a
Sprint may be different
for different teams

5.  In manufacturing “points” have been used for
decades, if not centuries
 Consider the concept of QUOTA
 Quota is the expected amount of delivery
over a period of time
◦ Similar to Points

6.  Quota could be based on the number of items
manually assembled, cars built, of feet of
insulation created
 A standard Quota is determined (velocity) via
initial trials and that is the set target
 Different stations may have different limits to
Work in Progress.
◦ You can run a line faster, but those on the receiving end
can only do so much
◦ Quality might be effected

7.  Staff normally get paid by the hour
 There is an expectation of meeting Quota
 If quota or quality is not met
◦ Root cause analysis is done
 Corrections are made
◦ Quota may be adjusted
◦ Summary: Quota and hours are related, but don’t
measure the same thing

8. 
Overall schedule and costs can be based on
◦ Expert Judgment
◦ Analogous Estimating
◦ Parametric Estimating
◦ Three-Point Estimating

Agile Rolling Wave estimation make
estimation hard

Bottom-Up Estimating (to Sprint level) is difficult

Estimation ranges for the Project are wider

9. 
“A Project can be estimated by dividing the
Product Backlog by Velocity”
 Statement made on LinkedIn

Why is this premise probably incorrect?
◦ Velocity is an “unknown” for several Sprints
◦ Rolling Wave requirements gathering delays information
◦ Agile, by its nature, encourages change
 Changes, which are expected, effect cost and duration
◦ Planning of Sprint points are normally only a few Sprints
ahead, not the full Project

Velocity is not consistent across multiple teams
◦ Such as SAFe, Less and other projects with multiple teams

10.  Point calculations for each Team is different
◦ Some teams are better at estimating
 Points for separate Teams should not be
combined.
 Points DO NOT EQUAL hours
 Actual Management error:
◦ Sum the point estimations for the teams
◦ Think that Points = Hours
◦ Wonder why “hours” aren’t being met

11.  Failure to include all factors in estimation
◦ Slack
◦ Error & Defect fixes
◦ Incomplete work
◦ Technical Debt / Spikes
 Velocity
◦ Based on delivered Points
◦ Should NOT include:
 Incomplete work
 Defective work found during integration
 Often occurs in Large Scale Projects (SAFe, LeSS, etc.)

12. Sprints Estimations
 Sprint Length is
determined by the
Scrum Team
 In SAFe and other large
scale projects the
Project or Program
Manager may be
involved in Sprint
Lengths
 Estimations can be
initially based on:
◦ T-shirt sizing
◦ Relative sizing
◦ Fist of 5
◦ Fibonacci methods
 New teams need time
to learn accurate
estimation techniques

13.  One month Sprints a probably too long
 Some Companies master day long Sprints
 In many cases a 2 week Sprint could align
with a 2 weeks payroll period
◦ “What value did you did you provide during that
period?”

14. Sprints Hours
 Points are:
◦ Effort for parts of work
◦ What is planned for
delivery in Sprint
◦ What was delivered as
part of the sprint
◦ What is incomplete?
 Hours are used for:
◦ Payroll
◦ Resource management
◦ Capacity Management
 If the “rule of Agile” is
broken – staff on
multiple projects
◦ Allocations are tracked
◦ Time may need to be
added for context
switching

15. Martin R. Bailey, PMP, ACP, CSM
MartinRBailey@gmail.com
www.linkedin.com/in/martinrbailey