UNIT-3

Techniques for Estimating: Estimates Are Shared, The Estimation Scale, Deriving
An Estimate, Planning Poker, Re-Estimating, Swim Stats Website, When Not To
Re-Estimate, When To Re-Estimate, Re-Estimating Partially Completed Stories,
The Purpose of Re-Estimating.
Estimates Are Shared
Estimates in agile teams are not created by a single individual
but are derived collaboratively by the team, including those who
will perform the work. This approach is essential because:
• Uncertainty in Task Assignment: On agile projects, it is not
always clear who will perform a specific task. Since anyone
may work on anything, it is important for everyone to
contribute to the estimate. Team Collaboration: Even if a
specific expert is expected to perform the task, others may
provide valuable insights.
• For example, a team member might point out past challenges or
overlooked complexities, leading to a more accurate
The Estimation Scale
Studies show that humans are best at estimating within one order of magnitude. To accommodate this,
agile teams use predefined non-linear estimation scales that reflect the increasing uncertainty associated
with larger tasks. Two commonly used scales are:
Fibonacci Sequence: 1, 2, 3, 5, 8. The gaps between numbers grow larger as the values increase, which
aligns with the uncertainty of larger tasks.
Doubling Sequence: 1, 2, 4, 8. Each number is twice the previous one, providing a simple progression.
Teams may also include 0 in the scale for tasks that require negligible effort. For larger tasks or epics,
additional values like 13, 20, 40, and 100 can be added to the scale. It is important to avoid false
precision, such as estimating tasks at 66 or 67 points, as humans cannot discern such small differences in
size.
The estimation scale helps teams categorize tasks into "buckets" of effort, ensuring consistency and
simplicity in the estimation process. 70,1,,7,82,5,90,1,5,a3,b4,c1,2,c8,d1,
Deriving An Estimate
The three primary techniques for deriving estimates are:
Expert Opinion: An expert provides an estimate based on
intuition or gut feel. This method is quick and can be
surprisingly accurate, but it is less useful in agile projects
where tasks require cross-functional skills.

Analogy: Estimators compare the task to similar past tasks.

Triangulation is used to compare the task against multiple
reference points, improving accuracy. This method leverages the
human ability to estimate relative size better than absolute
size.

Disaggregation: Large tasks are broken into smaller, easier-to-

estimate pieces. This approach reduces uncertainty but must be
used carefully to avoid over-splitting, which can lead to
forgotten tasks or overly broad ranges of estimates.
Techniques for Estimating
Techniques for estimating involve determining the effort or
time required to complete a task or project. The chapter
emphasizes that while more effort can improve estimate
accuracy, there is a point of diminishing returns where
additional effort yields little value. Agile teams focus on
quick, collaborative, and reasonably accurate estimates
rather than perfect ones. The three main techniques for
estimating are:
Expert Opinion: Relying on an expert's intuition or gut feel
to provide an estimate.
Analogy: Comparing the task to similar past tasks to
estimate relative size or effort.
Disaggregation: Breaking down large tasks into smaller, more
manageable pieces for easier estimation.
These techniques can be combined for better results, and
agile teams often use tools like planning poker to
collaboratively estimate tasks in a fun and efficient way.
Deriving an estimate
1. Expert Opinion
This is one of the simplest approaches where an experienced
individual (or subject-matter expert) provides estimates based on
intuition or past experience. The advantage is speed, as it often
takes little time, but the drawback is bias and dependency on a
single person’s perspective. In agile projects, it is less
effective since features often require multiple skills, making it
difficult for one expert to assess the effort across all
disciplines.
2. Analogy
Estimating by analogy means comparing the current task or user
3. Disaggregation
This technique involves breaking down large tasks or stories into
smaller, more manageable pieces. Large stories are notoriously
hard to estimate, but smaller ones (within the same order of
magnitude as others) can be estimated more reliably. However,
there is a risk of over-fragmentation, which can introduce errors
or omissions. The key is to balance decomposition without making
estimates unnecessarily complex
4. Planning Poker
Planning Poker is a collaborative estimation method widely used in
agile teams. Each participant is given cards with values (commonly
Fibonacci numbers: 0, 1, 2, 3, 5, 8, 13, etc.). A story is presented,
discussed briefly, and each member chooses a card privately. Everyone
reveals simultaneously. If estimates differ, discussion follows often
the high and low estimators explain their reasoning. The process
repeats until consensus is reached.
Planning Poker effectively combines expert opinion, analogy, and
disaggregation while encouraging cross-team participation. It works
well because:
• It brings together diverse expertise.
• It forces justification of estimates, reducing bias.
Example: Building a Login Page
[Link] Presentation
The product owner tells the team:
“We need to build a login page with username and password fields and
a ‘Login’ button. If the password is wrong, an error message should
be displayed.”
[Link] Questions
Team members ask questions like:
Do we also need a “Forgot Password” option?
Should the page be mobile responsive?
Is the backend API already available, or do we need to build it?
These questions help clarify the scope of the work.
[Link] Estimation (Secret Card Selection)
Each team member secretly chooses a card from their deck (with numbers
like 1, 2, 3, 5, 8, 13, etc.).
Suppose:
Ajay selects 3
Seema selects 5
Ravi selects 8
[Link] the Cards
Everyone shows their cards at the same time.
Now we see different estimates: 3, 5, and 8.
[Link]
• Ravi (8) says: “I think it will take longer because we may need to
build the backend API ourselves.”
6. Re-Estimation
• After discussion, everyone selects a card again.
• This time, all three pick 5.
• The team agrees that the login page should be estimated at 5
story points.
5. Supporting Practices
• Estimation Scales: Non-linear scales (like Fibonacci: 1, 2, 3,
5, 8) are preferred since uncertainty grows with task size.
Larger items can use extended scales (13, 20, 40, 100).
• Shared Estimates: Agile teams emphasize collective estimation,
not just relying on one individual.
• Effort vs Accuracy Trade-off: Spending excessive time on
estimation does not guarantee higher accuracy. Agile embraces
“just enough” estimation rather than exhaustive, upfront effort
When to play the poker game : Planning Poker should be played at
two key times:
Before the Project Begins or Early in the Project:
Teams typically estimate a large number of items before the
project officially starts or during its first iterations.
This may require two or three meetings, each lasting 1–3 hours,
depending on the number of items, team size, and the product
owner's ability to clarify requirements.
Ongoing During the Project:
Teams estimate new stories identified during an iteration.
A short estimation meeting near the end of each iteration is
often sufficient to estimate new work for prioritization in the
next iteration. Alternatively, teams can use a system like
Why planning poker works :Planning Poker works effectively for
the following reasons:
Combines Expert Opinions: It gathers multiple expert opinions
from a cross-functional team, ensuring diverse perspectives and
better-suited estimations.
Encourages Justification and Dialogue: Estimators justify their
estimates, leading to improved accuracy, better compensation for
missing information, and addressing uncertainty in user stories.
Benefits of Group Discussion: Studies show that group discussions
and averaging individual estimates result in more accurate
outcomes, which Planning Poker facilitates.
Handles Uncertainty: The process is designed to deal with the
vagueness of user stories, making it ideal for agile projects.
Re-Estimate :Re-estimating is the process of revisiting and
adjusting estimates for user stories or features during a project
to ensure plans remain realistic and aligned with the current
understanding of the work. It is typically done when the
relative size of a story changes based on new knowledge or
insights. Key aspects of re-estimating include:
When Not to Re-Estimate:
Avoid re-estimating solely based on the time taken to complete a
story, as velocity will self-correct over time.
Do not mix revised estimates for completed stories with original
estimates for remaining ones, as this can distort the project
plan.
When to Re-Estimate:
Re-estimate when the relative size of a story changes compared to
Examples of Re-Estimating:

• Adjusting estimates after realizing that certain tasks, like

charting stories, are more complex than initially thought.

• Revising the project timeline after the first iteration when

the team completed fewer points than planned.

• Estimating new features or adjusting priorities, such as adding

characters or online play, and recalculating the timeline

accordingly.

• Using velocity (average points completed per iteration) to

Purpose and Benefits:

• Improves future estimates by learning from past inaccuracies.

• Keeps plans realistic and aligned with current priorities and

progress.

• Helps manage risks and set realistic expectations for

stakeholders.

Best Practices:

• Re-estimate only when necessary to maintain consistency.

Swim Stats Website
• Its serves as a hypothetical case study that serves as the
foundation for the re-estimation discussion

The SwimStats website is imagined as a web-based platform for

swimmers, swim coaches, and officials:
• For coaches: it allows maintaining a roster of swimmers,
organizing workout sessions, and preparing for meets.
• For swimmers: it provides access to meet results, personal
records, and progress tracking over time.
• For officials: it offers a way to directly enter meet results
into the system.

• The SwimStats Website case study is useful for explaining re-

estimation because it provides a practical, relatable set of
user stories where teams can apply estimation principles and
see what happens if they adjust (or don’t adjust) estimates.
SwimStats isn’t a real website:

• It provides realistic user stories (e.g., entering swimmer demographics, viewing times,
uploading results).

• These stories are used to demonstrate when to re-estimate and when not to re-estimate.

• It anchors abstract concepts like velocity, story points, and relative sizing to a tangible scenario
coaches and swimmers can relate to.
1. Gives a Realistic Context
Instead of talking about abstract “Story A” or “Task B,” Swim
Stats introduces user stories that feel real:
As a coach, I can enter swimmer demographics.
As a swimmer, I can see all of my times for a specific event.
As a coach, I can upload meet results.
This realism makes it easier to understand how different kinds of
work might vary in complexity and why estimates might need
adjustment.
2. Shows When Not to Re-Estimate
Using SwimStats stories, the text shows a common mistake:
The team thinks a story was “bigger” than expected and doubles
its points after finishing.
But if all similar stories are also doubled, the total remaining
work increases too, so the project timeline doesn’t really
change.

Don’t re-estimate just because a story took longer than you

thought. Velocity will naturally correct for this.
3. Shows When to Re-Estimate
With SwimStats charting stories, the team realizes one story
(“show line chart”) was much harder than expected, and others
of the same type will likely be harder too.
Here, relative size changed — charting stories are consistently
underestimated.
Re-estimating all charting stories gives a more accurate
reflection of workload.
Only re-estimate when your understanding of relative size
across stories changes.
4. Explains Partially Completed Work
In SwimStats, one story (“system recommends who should swim in
each event”) is partially finished.
The team can either take an all-or-nothing approach (credit only
when done) or split the story into smaller ones and re-estimate.
Re-estimation helps handle partially completed or overly large
stories in a fair, consistent way.
5. Connects Back to Velocity
By using SwimStats, the text emphasizes that velocity is the
equalizer.
Even if estimates aren’t perfect, velocity trends over several
iterations give a reliable forecast.
The SwimStats case helps show how bad practices (like re-
estimating completed stories) distort velocity, while good
practices (re-estimating when relative size truly shifts) keep
velocity meaningful.
 Topic Guideline Example Key Point
Entering swimmer
Don’t change story points demographics was estimated as Let velocity handle
When Not to Re-
just because a story took 3 points but took longer. Keep inaccuracies. Keep estimates
Estimate
longer than expected. it 3 points and let velocity consistent.
adjust.
Re-estimate when you
All charting stories (line, pie,
realize a whole category of
bar charts) are harder than Re-estimate when relative size
When to Re-Estimate stories was
expected → double their understanding changes.
underestimated/overestimat
points.
ed.
If a story is only partly Story: “System recommends
Re-Estimating done, either count nothing swimmers for all events” (5 Best to keep stories small. If
Partially Completed (all-or-nothing) OR split it pts). Done: individual events (3 large, split and re-estimate
Stories into smaller stories and re- pts). Remaining: relays (new fairly.
estimate. story).
To fix wrong relative sizes Charting stories were
Use re-estimation as a learning
Purpose of Re- and learn for future underestimated → re-estimate,
tool. Failure to learn = true
Estimating estimates, not to account so planning is more accurate in
failure.