Agile estimation involves estimating at multiple levels: 1) Product roadmap uses high-level estimates like 12 months to sequence features by business value and cost. 2) Release planning estimates in story points to prioritize features for the next 4 iterations based on team velocity. 3) Iteration planning breaks down epics and estimates user stories in story points or t-shirt sizes for the current sprint. Relative estimation methods like planning poker and fibonacci sequence are preferred over absolute estimates due to uncertainty in large projects. Regular refinement of estimates is important in agile.

1. Agile estimation
Dinesh Singh Panwar

2. AGENDA
• Context: Where estimation fits in Agile
• Product Roadmap and sizing
• Release planning and sizing
• Sprint/Iteration planning and sizing
• Relative estimation vs Time/Effort estimation
• T-Shirt Sizing
• Exponential sizing – Fibonacci sizing
• Known issues with agile estimation

3. Context – Where estimation fits in Agile
Product Roadmap uses High Level
estimation (EXAMPLE = 12 MONTHS)
Sequence the list of features by Business
Value and cost to build
Release 1 = Backbone + Must have
Release 2 .. N = Weighted shorted job first
Release Plan (EXAMPLE 2 MONTHS)
Feature prioritization for next 4
iterations using Feature to Epic
breakdown estimation
Iteration Plan (EXAMPLE 2 weeks)
Epic to User Story breakdown and
estimate

4. Product Road map & Sizing – Breadth
First, Depth later
Release Type Candidature
Backbone
2 iteration
CORE Sizing
(NO PRODUCT
without it)
MVP
2 iterations
MUST HAVE
(Negotiable)
Expansion
4 iterations
Prioritize Next
Automation
4 iterations
Icing on the
cake
At Initial Road-Map - We Only need to estimate Backbone and MVP in detail and high level for
future
After every release, we re-estimate Future iteration to refine
T-Shirt Size for viability of features in MVP and backbone.

5. Release Planning estimations
 Estimate For Next Release ( 4 iterations) in “Story Points”
 Judge team iteration capacity(i.e Story point velocity) –
 For mature team, use previous actual vs estimated data to find “actual Story Point velocity”
 for fresh team engineer traditional guestimate
 Team of 3 = 30 man-days per iteration (2 weeks),
 Lets say 1 story is 3 person day, that’s 10 Story Point per iteration
 Pull Prioritized items from Backlog just enough to “fit” in 4 iterations in Order
 Breakdown Immediate Iteration Features to Epics/ User Stories and revise estimate
 Key Methods – Story points – Relative estimation , Story Breakdown
Team Velocity 10 Story point
# Relaese Goal Backlog Prioritized T Shirt Story Points Iteration 1 Iteration 2 Iteration 3 Iteration 4
1MVP Incident L 13X X
Core Data S 5 X
CORE SLA XS 3 X X
AD Integration XS 2 X
KT XS 1 X
2Expansion Problem M 8 X X
Portal - Branding S 5 X
Catalog 1 M 3
Catalog 2 S
Catalog 3 M
CMDB - Integration M
Single Signon M
Monitoring integration

6. Iteration Planning estimation
 Perform Refined Iteration after each Iteration and plan
 Story Breakdown Example
 Hypothetically Incident Feature consists of
 EPIC: Incident Lodgment changes
 Story: 1 As a Service Desk Agent, I shall be able to capture blah blah
 EPIC: Incident Workflow changes
 Story 2: As a Support Team, I shall able to put Status to pending blah blah so that SLA blah blah
 EPIC: Reporting and Governance
 Story 3: As Operations manager, I shall be able to blah blah to control cost blah blah
 Re-estimate and re-plan the items in the Sprint, if estimate is less, feel free to pull more items OR if it’s more go back to PO (you may be
able to negotiate some stories out to future releases)
 Story 1 = 5
 Story 2 = 3
 Story 3 = 3

7. Relative Estimation vs Absolute
 Humans are terrible in Absolute estimation
especially for bigger and unclear items
 Humans are amazing in relative estimation
 Software work is like a gas, it will
generally fit into reasonable sized
container.
 According to various experiments and
theory, the uncertainty in Information
flow increases exponentially over time &
size and that is the reason we cant do
absolute estimation of large software
build
PM/AM: How long would it take to install SNOW instance
Consultant: 5 hours
PM/AM: Wow that’s specific
Consultant: I done it many times and I have got all the
data from customer
PM/AM: How long would it take to deploy full Key Start
solution
Consultant: 1 month
PM/AM: You mean 172 hours
Consultant: … Ah …. Yeah ….. About that….
PM/AM: Have you factored in 2 days holiday this month?
Consultant: Doesn’t matter, we can squeeze within a
month. The whole work is about 4 times of Core
implementation that roughly takes 1 week for this
customer.

8. T Shirt Sizing – Relative BallPark
 XXS (User Load)
 XS (Instance creation)
 S (Configure Incident Management)
 M (Implement Horizon)
 L (Fully automated integration between HP Service desk and SNOW)
 XL (ITOM implementation)
 XXL (Create a Horizon Style product for SecOps)

9. Exponential estimation
 1,2,3,5,8,13,21,34. Fibonacci sequence
 “If team is confident they can do a work in 9 days, they surely can do it in 8 days”
 “if a team is under-confident in doing a work in 9 days, it will probably take them 13
days”
 Why it’s popular
 Allows precise estimation for smaller items & ball-park of larger items
 Generally follows exponential graph, in line with various theories of Information
uncertainties
 Easy calculation. Removes fight over small variations (choice between 21 points and 34
points is easy)
 Can be used in Story Points to “size” backlog items relatively
 Gives objectivity to theories

10. Known Issues:
“Democracy has lots of issues, but it is still the best form of governance
framework known to mankind”
 When First Release, First iteration, there is NO Story velocity data and NO Effort conversion data to
arrive at planning
 Mitigation: Use guestimates on the basis of team size and slack; You are unlikely to have extreme variance for 2
weeks worth of work (Remember Humans are good in estimating small work)
 Collaborative Estimation is influenced by paygrade
 If Architect says 5 story point, developer will be reluctant to say 8
 Mitigation: Use Planning games like planning poker
 T-Shirt Sizing does NOT give numbers
 Mitigation: Use it only for comparative decision making and use exponential in more granular estimates
 Story point estimation requires continual refinement and stakeholder approvals
 Manage stakeholder expectation and involvement various ceremonies (That’s why they say Agile is all about
culture change)
 Teams may do Over-estimation to show High Velocity in future iterations
 Honest Teams, re-calibrate their Point system by comparing back to similar size stories of previous iterations