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