Project estimation is one of the few activities that every delivery framework like Hybrid, Agile, Scrum, Waterfall, or ad-hoc agrees on. This is even if the platform and participants disagree on how, why, and when to do it. Whether one subscribes to predictive planning, adaptive delivery, or somewhere in between, estimations are the mechanism Project Leaders use to transform uncertainty into dialogue, alignment, and expectations. Yet estimations are often misunderstood as a single number instead of what it truly is
Estimations are a living agreement about effort, complexity, and risk.
When estimations are treated as a one‑time event, they quickly become disconnected from the reality of the situation. When they are treated as an evolving discipline, done early and revisited often, they become one of the most powerful tools a Project Leader has.
My favorite estimation accessory: Planning Poker Cards – Set of 4 Decks – Stationery for Agile Scrum – Estimation Fibonacci Cards
Different Ways to Measure Size (and Why None Are “Perfect”)
There is no universal unit of estimation that works for every team, organization, or phase of delivery. The value comes from choosing a sizing approach that fits the context and then using it consistently.
Hours (Strictly Time-Based Estimation)
Estimating in hours is the most familiar approach and often the most dangerous when determined too early in the process. Hours imply certainty, precision, and a known path forward and work best when we have the following.
- The work is well understood and defined
- The task is repeatable
- Historical data exists for reference
The challenge with hour‑based estimates is not the math or calculations it’s the psychology. People feel pressured to defend them and Stakeholders treat them as commitments rather than forecasts. Hours should be a translation layer later in planning, not the starting point when uncertainty is high.
Fibonacci Scale (Relative Complexity)
Using a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, and so on) forces teams to think in relative size, not false through precision. The wider the gap between numbers, the acknowledgment that uncertainty grows as complexity increases. This approach is particularly effective when we are examining items like the following.
- Comparing work items directly to each other
- Highlighting uncertainty of estimations rather than hiding it
- Encouraging discussion instead of debate about possibilities
The number itself matters far less than the conversation that produces it.
More on this here: SECRETS ON FIBONACCI TRADING: Mastering Fibonacci Techniques In Less Than 3 Days
T‑Shirt Sizes (XS–XL)
T‑shirt size estimation intentionally removes numbers and time then replaces them with categorical sizing to express relative scope, complexity, and uncertainty. This approach is most effective early in an initiative, when the goal is not delivery precision but shared understanding across teams and stakeholders we can use any of the following.
- XS = Extra Small
- S = Small
- M = Medium
- L = Large
- XL = Extra Large
By forcing conversations around whether something feels “Small” versus “Large,” teams naturally surface assumptions, unknowns, dependencies, and risk without the pressure of defending artificial precision. The simplicity of this model also makes it accessible to non‑technical audiences, enabling faster alignment and decision‑making at higher levels of the organization.
T‑shirt sizing works well when we are dealing with the following.
- Early roadmaps and portfolio intake where detail is limited
- Epics, major features, or large initiatives that will be decomposed later
- Executive and stakeholder communication where relative size matters more than task‑level accuracy
- Prioritization discussions focused on sequencing and investment trade‑offs
- Situations where discovery is still underway and uncertainty is high
The downside is clear: T‑shirt sizes cannot be directly converted into timelines or schedules without further refinement. This is not a weakness of the approach, but a signal that additional discovery, decomposition, and clarification are required before more precise estimation techniques can responsibly be applied.
More on this here: Agile Estimating and Planning: A Modern Guide (Agile Delivery Mastery Series)
Number of Cards Completed (Throughput-Based)
Some teams estimate by measuring how much work they typically complete over time, not by predicting the size of future tasks. This approach relies on flow and historical throughput rather than speculative sizing. This type works best when all is had is the following.
- Work items are relatively uniform
- Teams are stable
- Focus is on sureness rather than accuracy
The estimate emerges from behavior, not planning.
More on this here: Agile Estimating and Planning (Robert C. Martin Series)
Story Points
Story points combine relative sizing with team‑specific calibration and fears of not being able to be accurate. Two teams can assign very different point values to the same work while both can be correct at being wrong. Story points are effective because of the following.
- Decouple effort from time
- Account for complexity, risk, and unknowns
- Improve forecasting when paired with real delivery data
- Can be changed when someone decides to
They only fail when organizations try to standardize them across teams or convert them directly into actual hours.
More on this here: Agile Estimation Distilled: Demystifying Agile Estimation
Why Estimation Must Happen Early and are Revisited Often
Early estimation creates direction, not certainty. It allows teams to understand some of the following.
- Alignment of scope to capacity
- Surfacing of risks while they are still cheap to address
- Awareness of informed trade‑off decisions
Early estimates should never be the last estimates for a project, phase, iteration, epic, or summary task. As work progresses and uncertainty collapses into knowledge allowing for estimates to be refined. Re‑estimating is not admitting failure, though for some it appears as such along with thoughts that it is a waste of time. Re-estimating is evidence that learning is happening and projects that never revise their estimates are often the ones least connected with reality.
Agreeing on Size Before Work Begins
One of the most overlooked steps in estimation is explicit agreement on what is being sized.
- Versions
- Phases
- Summary Tasks
- Releases
- Epics
- Stories
- Cards
- Tasks
- Tickets
- Issues
- Bugs
Each of those above work packages represent a different level of abstraction and attention. Estimating these without clarifying that level leads to misalignment before work even begins. A story‑level estimate cannot safely be rolled up to a release without understanding the following.
- Dependencies
- Integration effort
- Non‑functional requirements
- Review and approval cycles
- Environmental and platform constraints
- Data considerations and migration effort
- Security, compliance, and regulatory requirements
- Testing scope and effort
- Operational readiness and enablement
Agreement on sizing does not mean that we come to full consensus on numbers alone. Agreement means shared understanding of on the following.
- What “done” looks like
- What is included—and explicitly excluded
- Where uncertainty still exists
- Assumptions being made
- Key risks
- Illustrated constraints
- Expected level of quality and completeness
- Acceptance criteria or validation approach
Without those agreements, estimation becomes an argument instead of a planning tool.
Perspective Shapes Perceived Progress
One of the most difficult truths in project delivery for Project Leaders is this that progress is subjective until value is visible.
It is entirely possible for one person to say “we’re 90% done” while another sees 0% usable output… and for both to be correct and wrong.
From one individual’s point of view:
- Research is complete
- Design decisions are made
- Code paths are written
From a stakeholder’s point of view:
- Nothing can be used
- Nothing can be validated
- Nothing can be released
This disconnect is not incompetence, it’s plainly described as perspective. Perspective is part of everyone’s world and can absolutely be partially understood…
Estimation and progress reporting must account for this by distinguishing between the following items.
- Effort expended
- Work completed
- Value realized
Until something produces an observable, usable outcome, its perceived completion will vary wildly depending on who is looking.
Estimation as a Conversation, not a Contract
The most successful implementations don’t treat estimates as promises or absolutes. They treat them as signals of complexity, risk, change, and learning.
- When estimation is used to punish deviation, resources stop being honest. When it’s used to encourage dialogue, teams get smarter over time.
- The real goal of project estimation is not to be “right.” It’s to be aligned, transparent, and adaptable.
When implementers share a common language related to sizing, revisit their assumptions often, and respect that status looks different from different viewpoints, estimations become what it was always meant to be. It becomes a tool for clarity in a world full of uncertainty.
Close-out and Shot-down
Estimations are not about predicting the future with perfect accuracy because by nature, they are wrong. They are about creating shared understanding in the present and when reduced to a single number, they lose their purpose and become a source of tension, false confidence, or premature commitment. When estimations are treated as a conversation grounded in context, perspective, and learning they become a stabilizing force in an otherwise uncertain environment.
Effective estimation acknowledges what we know, what we assume, and what we do not yet understand. Respecting that different work items operate at different levels of abstraction, that progress looks different depending on where you stand, and that certainty grows only through execution and feedback. It also accepts that estimates must evolve as knowledge replaces assumptions.
The most successful Project Leaders do not chase “perfect estimates.” We foster alignment, revisit decisions, and create space for transparency. We understand that agreement is not about unanimous numbers, but about shared expectations, clearly defined outcomes, and an honest view of risk and readiness.