Estimating the size and effort required for projects and tasks is important for planning purposes but difficult to do with precision. Estimates are informed guesses that can vary due to factors like unclear requirements, lack of historical data, and scope changes. While estimates are not perfect, they provide value by enabling prioritization, collaboration, and iterative planning. Effective estimation techniques include using ranges rather than single points, factoring in assumptions, combining expert judgement with data-driven methods, and refining estimates over time as understanding improves.

1. 1
The Art of Estimation

2. 2
➢ How long will it take to read 500 page thick book?
➢ How long will it take to drive to a particular city or state?
➢ How much money it will take to organize a b’day party?
What is estimate?
➢ How long will it take for you to build a sand castle like this:
“As the size and complexity increases, it becomes almost impossible to give a precise
estimate”
“There is no such thing as accurate estimate. Estimate is an informed guess (a probability)
which can be different from actual. Variance is a reality which we need to accept.”

3. 3
Estimation – Reason of Variance
No Historic Data
Unclear Requirements
Lack of Domain or
technical knowledge
Scope Creep
Non-developer Estimating
Variance
➢ Just for an illustration, imagine each of the variance source causes 30% variance then
cumulative range of variance could be: - “1 – 1.3*1.3*1.3*1.3*1.3” = “1 – 3.7” => 270%
variance
➢ If can’t estimate accurately then why estimate? Some Lean/Kanban experts believe
“Estimate is overhead. It’s waste.”. There is “#Noestimate” movement.

4. 4
Estimation Advantages
➢ Sponsor and end customers expect early information about cost and timelines.
➢ Estimation help in managing projects interdependencies and organizational
dependencies.
➢ Estimation helps in understanding the viability. It helps to identify early on,
anything not worth pursuing.
➢ Estimation helps in prioritization as prioritization is not just function of value but
value & cost (ROI) ratio.
➢ Estimation helps in better planning and execution.
➢ Estimation provides another opportunity to collaborate and get better
understanding of ‘What’ and ‘How’ (requirements and implementation).

5. 5
Estimation Basics / Tips
➢ Estimate in range rather than giving a single figure. Example: It would take 15-30
minutes to reach office depending on traffic conditions.
“It’s better to be roughly right than precisely wrong” – John Maynard
Keynes.
➢ Any estimate is as good as its underlying reasoning and assumptions. Example:
While giving this estimate for time to reach office, I am assuming private vehicle
rather than public transport and travel during non-peak traffic hours.
➢ Historic data (past projects) is good for estimation.
➢ Current data (current project) is even better and that’s where agile focuses.
➢ Estimation is not a one time activity. It is done iteratively as we progressively
elaborate the project’s ‘what’ and ‘how’ so modify it when you learn anything new.

6. 6
Estimation cone of uncertainty
The cone
doesn’t narrow
itself.
We have to
force it to narrow
by reducing
variability.

7. 7
Estimation Techniques
➢ Expert Judgement
➢ Analogous / Top Down Estimate – Estimating based on analogy with other
similar projects done in past.
➢ Used when very little information is available. Estimates are known as Rough
Order of Magnitude or ballpark estimates.
➢ Parametric Estimate – Uses statistical relationship between historical data and
other variables to calculate and estimate.
➢ Micro / Bottom-up estimate – Require a detailed WBS (Work breakdown
structure), activity list and resources. Estimate is summation of individual
estimates of small parts.
We combine techniques. Expert Judgement or analogous estimate in the beginning
when less information is available. Use bottom-up or other detailed estimation
techniques later on.

8. 8
Wide Band Delphi
Delphi is structured way to create forecast based on inputs from panel of experts.
Wideband Delphi is a variation of that with following steps:
1) Choose the team – Select moderator and estimation team considering
representation from all areas (eg development, testing, devops, product etc)
2) Kick Off Meeting – Moderator leads a discussion to brainstorm assumptions,
WBS, units of estimation etc
3) Individual Preparation – Estimators individually prepare tasks list, estimate and
assumptions
4) Estimation Session – Discussion on estimation range and outliers. Attempt is to
gain consensus on estimate, tasks list and assumptions.
5) Assemble Tasks – Compilation of final tasks list, estimate and assumptions.
6) Review Results

9. 9
Wide Band Delphi

10. 10
PERT – 3 Point estimation
➢ Scope is broken down into components / activities / work packages. Each
component is given 3 estimates – Optimistic (O), Pessimistic (P), Most Likely (M)
➢ Estimate used for planning = (O+4M+P) / 6
➢ Standard Error for each component σte = (p - o) ÷ 6
➢ Risk Spread
Example: Say we have only two tasks:
1) Task 1 – Optimistic estimate 5; Most likely 8; Pessimistic 11
2) Task 2 – Optimistic estimate 3; Most likely 6; Pessimistic 12
Estimate = (5+4*8+11)/6 + (3+4*6+12)/6 = 13.5
Risk Spread = SQRT (SQR((11-5)/6) + SQR((12-3)/6)) = 1.8
This gives estimate range of 11.8 to 15.3 instead of 8 to 23. Adding 2*risk spread
givens 95% confidence estimate which is 17.1 in this case.

11. 11
Affinity Estimation
➢ Done as first round of estimation for:
➢ Providing initial view of size to PO for
prioritization.
➢ Team to identify items too big or too
complex for possible split / spikes.
➢ It has five steps:
1. Silent Relative Sizing
2. Discussion to edit the wall
3. Place items into relative size buckets
4. Product owner challenge
5. Store the data in electronic tool

12. 12
Ideal days / hours estimation
➢ Ideal Time is - How long something would take if
a) It’s all you work on
b) You have no interruptions
c) You have all you need
➢ Elapsed time is total time taken to finish the work
➢ Ideal time for a American footwall game is 60 minutes – Four 15 minutes quarters.
The elapsed time is much longer and hard to accurately predict.
➢ Ideal Days estimate is easy to estimate (at least initially) and explain but hard to
convert into elapsed time.
➢ Trainings, meetings, phone calls and task switching etc affect difference between
ideal time and elapsed time.

13. 13
Relative Estimation
➢ Giving measurement baselines will not help because:
a) It’s very difficult and time consuming to measure.
b) Given dimensions may not be accurate and result in most going to a single box.
➢ Triangulation will help. Triangulation means comparing each sample with multiple
other samples.
➢ Relative estimation is slow and difficult in the beginning but once you have estimated
few, it will be fast and easy.
Small
Medium
Large
Can you divide mangoes from this huge pile into three boxes based on size?
Do you need to be told the exact dimension, length, width etc to identify different sizes?

14. 14
Story Point Estimation
➢ Story Points is unit-less, relative size estimate which factor in both size (how much there
is?) and complexity (how hard it is?).
➢ Relative size is what is important.
➢ Example: Login Feature is 2; Search is 8 (as it’s approx 4 times bigger and harder
than Login Feature).
➢ Smallest story point could be of 1 story point
➢ Don’t use a single gold standard, rather triangulate i.e. compare with multiple reference
stories
➢ Basic math function (addition / subtraction still hold good).
➢ Each team defines these unit less points as they see fit. Can’t compare story point
estimates of two teams.
➢ Teams often defines handful of stories as reference stories to help with estimation
process.

15. 15
Benefits of story point estimation
➢ Faster & Easier - Once team get a hang of it, story point estimation is much faster and
easier than day/hours estimate.
➢ Drive cross-functional behavior – It helps drive cross functional behavior as whole team
needs to provide single story point estimate for given user story.
➢ Don’t change with time – With time as team becomes more efficient or gets inefficiencies,
effort estimate in days/hours for same work changes which make it difficult to separate
efficiency change from estimate change. No such issue with story point estimation as it’s
relative.
➢ Avoids elapsed time vs effort confusion - Invariably ‘x’ days estimated work is supposed
to be finished in ‘x’ days which is often not true.
➢ Story point estimation is difficult for new agile teams so one mid-way approach could be:
a) Define “1 story point = 1 ideal day”
b) Gradually convert team to thinking in unit-less story points and unlearn a)

16. 16
Agile Estimation – Just in time
Each of the priority items has a
size estimate in story point or
ideal days
Very large item at the bottom(which
may not be for current release) may
not have estimate or may have
estimate in large units
As items move up in the
priority list of unfinished
items, these are refined
further for better estimate
Accuracy
2
3
1
3
5
8
3
13
20
40
100
L
XL

17. 17
Story point estimationAccuracy
Effort
➢ A little effort helps a lot but then lot of effort
only helps a little more.
➢ Agile doesn’t believe in too much precision
and want just enough precision to allow
planning. That’s the key reason for using
non-linear scale.

18. 18
Using the right scale
➢ Can you decide whether given story is a one point story OR a two points story?
➢ How about deciding whether given story is a 14 points story OR a 15 points story?
➢ Use a non-linear scale. Two commonly used scales are:
a) Fibonacci Series – 1,2, 3, 5, 8, 13, 20, 40, 100…
b) Power of two – 1, 2, 4, 8, 16…
➢ For work to be done in near future, stay within single order of magnitude i.e. range
1 – 10
➢ Include 0 or ½ if required.
➢ Zero helps in considering trivial efforts.
➢ Remember 15x0 != 0. Multiple zero point stories can be combined to make 1-
2 points stories.

19. 19
Planning Poker
➢ A gamified variation of Delphi estimation
where estimators are those who will do the
work.
➢ Improves buy-in and team collaboration.
➢ Each estimator is given a deck of cards, each
card has a valid estimate written on it (based
on non-linear scale chosen)
➢ Customer/Product owner reads a story and
it’s discussed briefly
➢ Each estimator selects a card that’s his or her
estimate. Cards are turned over so all can see
them
➢ Discuss differences (especially outliers) and
re-estimate until estimates converge

20. 20
Planning Poker
➢ Team can also use question mark or infinity to
denote high size and complexity preventing
them to estimate properly i.e. need for split,
spike or scope clarity.
➢ Lack of convergence after 2-3 rounds require
scrum master to understand the reasoning and
deal case on case basis. Often these items are
parked aside.
➢ Product owner doesn’t estimate but is present
to answer any queries around scope.
➢ Engineering managers also don’t estimate but
support the process and sometimes provide
inputs.
Estimators Round 1 Round 2
Tara 3 5
Bala 8 5
Joju 2 5
Chris 5 8

21. 21
➢ Velocity is sum of total estimate (in story points or ideal days) of stories which qualifies
“Definition of Done” in a given sprint.
➢ Example: Team signed up 5 stories of 3 points each (15 USP); 4 stories got DONE and 1
is incomplete then velocity is 12 USP).
➢ This helps in creating forecasts and planning for next sprints.
➢ Schedule = (Total number of story points / velocity)*Iteration length
➢ Velocity gets stabilized after running few iterations and we often take average of last 3
sprints.
➢ It corrects estimation errors and automatically factors in non-productive activities,
unplanned distractions.
Backlog Size Velocity Duration
200 Points Velocity = 25 200/25 = 8
Iterations
Velocity

22. 22
Burndown and Burnup charts

23. 23
Appendix

24. 24
Estimation

25. 25
Determining Velocity
Good to have historic values
but as every project & team is
unique, these have limited
value
Use Historic Values
Ideal way if feasible. After each
iteration the range of possible
velocity figures will converge
Run an Iteration
Estimate based on team’s
capacity
Make Forecast
Velocity is not just a number but a range of optimistic and pessimistic scenarios.

26. 26
Velocity Forecast – Determine Team capacity
Person Hours Available per iteration
Tom 32 – 40
Harry 36 – 40
Rita 20 – 28
Han 16 – 22
Total Hours 104 – 130
Calculate Team’s capacity – An example
104 – 130 hrs effort available

27. 27
Velocity Forecast – Raw velocity exercise
Story Story
Points
As user.. Search 2
As admin... Add 5
As visitor .. Inquire 3
As admin .. clone 5
104 – 130 hrs effort available Task Hrs
Design 6
Code 12
Test 8
Total 26
Task Hrs
Design 10
Code 12
Test 12
Document 10
Automate 8
Total 52
Task Hrs
Design 10
Code 14
Test 12
Total 36
Task Hrs
… …
Total 54
Backlog
Effort = 26+52+36 = 114
Velocity= 2+5+3=10

28. 28