"How long will this take?" is the question every stakeholder asks. "It depends" is the honest answer, but not a helpful one.
Effort units bridge this gap — giving stakeholders transparency while acknowledging uncertainty.
What Are Effort Units?
Effort units measure complexity and effort, not time. Think of them as relative sizing:
- 1 point: Trivial (change button text, fix a typo)
- 2 points: Small (add a form field, update a color scheme)
- 3 points: Simple (add form validation, create a basic API endpoint)
- 5 points: Medium (build a CRUD interface, implement search with filters)
- 8 points: Complex (third-party integration, real-time data sync)
- 13 points: Very complex (payment processing, multi-step wizard)
- 21 points: Large (complex business logic with multiple integrations)
- 34 points: Very large (full subsystem, e.g. notification engine with multiple channels)
- 55 points: Exceptional (cross-cutting platform change, major migration)
- 89 points: Maximum — reserved for rare, well-scoped project milestones that resist further breakdown
We use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89) because the gaps between numbers grow larger as complexity increases. The difference between a 1-point and a 2-point task is small. The difference between a 13-point and a 21-point task is significant — and that gap reflects the increasing uncertainty in larger work. Most feature requests fall in the 1–21 range; anything above 34 is exceptional and should usually be broken into smaller feature requests.
Why Not Just Use Hours?
We used to estimate in hours. Here's why we switched.
Developer Speed Varies
The same task takes different amounts of time depending on who does it, what tools they use, and how familiar they are with the codebase. Hours penalize honesty — if you estimate high, you look slow; if you estimate low, you miss deadlines.
Effort units separate the question of "how complex is this?" from "how long will it take this specific person?"
Research published in IEEE Software[1] found that expert estimation, particularly relative estimation techniques like effort units, tends to be more accurate than algorithmic models for software projects. The key advantage is that relative sizing (comparing tasks to each other) is cognitively easier and more reliable than absolute estimation (predicting hours).
Unknown Unknowns
That "5-hour task" becomes 15 hours when you discover undocumented API quirks, legacy code incompatibilities, or security requirements nobody mentioned. Hours pretend we know more than we do.
Effort units embrace uncertainty. A 5-point task is complex regardless of what surprises it contains.
Pressure to Underestimate
When you estimate hours, there's pressure to lowball. "Can you do it in 40 hours instead of 60?" is a common negotiation. The developer says yes, then either cuts corners or misses the deadline.
Effort units remove this pressure. They're abstract enough that nobody argues "can you do it in 5 points instead of 8?"
The VersionOne (now Digital.ai) State of Agile survey[2] has tracked agile practices globally for over a decade. Effort units remain the most popular estimation technique in agile teams, with relative estimation adopted by the majority of respondents. The technique's longevity speaks to its practical utility despite being "imprecise" by design.
How We Estimate
Step 1: Define Reference Feature Requests
We establish baseline complexity levels that the whole team agrees on:
1 Point — "Update Text"
├─ Change button label
├─ Update a color variable
└─ Fix a typo in copy
3 Points — "Simple Feature"
├─ Add a form field with validation
├─ Create a basic API endpoint
└─ Add unit tests for existing code
5 Points — "Standard Feature"
├─ Build a list view with pagination
├─ Add authentication flow
└─ Implement search with filters
8 Points — "Complex Feature"
├─ Integrate with a third-party API
├─ Build real-time data sync
└─ Implement complex business rules
13 Points — "Very Complex Feature"
├─ Payment processing integration
├─ Multi-step onboarding wizard
└─ Role-based permission system
Step 2: Relative Sizing
New tasks are compared to reference feature requests:
Question: "Is this notification system more like the 5-point search feature or the 8-point third-party integration?"
Answer: "It has external dependencies (email provider, push notifications) so it's closer to 8 points."
Step 3: Team Consensus
Multiple people estimate independently, then compare. If estimates differ significantly, the discussion reveals assumptions that need to be resolved. This takes 2-5 minutes per feature request and catches misunderstandings before work begins.
From Effort Units to Timeline
Effort units alone don't answer "when will it be done?" You need delivery speed.
What Is Delivery Speed?
Delivery speed is the number of effort units completed per development cycle. After a few development cycles, delivery speed stabilizes and becomes a reliable planning tool.
Example:
- Development cycle 1: 22 points completed
- Development cycle 2: 28 points completed
- Development cycle 3: 25 points completed
- Average delivery speed: 25 points/development cycle
Timeline Estimation
With a known delivery speed, timeline estimation is straightforward:
Project feature queue: 100 effort units
Team delivery speed: 25 points/development cycle
Development cycle length: 2 weeks
Timeline: 100 ÷ 25 = 4 development cycles = 8 weeks
This isn't a promise — it's a forecast based on historical data. Actual delivery speed varies development cycle to development cycle, which is why we re-forecast regularly.
Common Objections
"Effort units are arbitrary!"
Yes. So are hours. At least effort units admit they're estimates rather than pretending to be precise.
"Why not just use t-shirt sizes?"
We tried. Stakeholders ask "how many smalls fit in a development cycle?" and you're back to quantifying. Effort units are already quantified, which makes planning simpler.
"My team can't agree on estimates!"
That's a feature, not a bug. When one person says "3 points" and another says "13 points," they're seeing different things. The discussion that follows surfaces assumptions, clarifies requirements, and prevents surprises during implementation.
"This feels like extra overhead!"
Estimation takes time upfront. But it prevents costly mid-project surprises. A 30-minute planning session that catches a misunderstood requirement saves weeks of rework.
When Effort Units Go Wrong
Effort units aren't magic. They go wrong when:
- Estimates are never updated: If a 5-point task turns out to be 13 points mid-development cycle, say so. Stakeholders appreciate honesty more than false optimism.
- Points are used for performance reviews: Effort units measure complexity, not productivity. Using them to compare developers or teams defeats the purpose.
- Large feature requests aren't broken down: Anything over 13 points has too much uncertainty. Split it into smaller, better-understood feature requests.
- Delivery speed is treated as a target: Delivery speed is a measurement, not a goal. Pushing teams to "increase delivery speed" just leads to inflated estimates.
Best Practices
1. Re-estimate When Needed
If a task is harder than expected, update the estimate. This isn't failure — it's information that makes future estimates more accurate.
2. Track Delivery Speed Over Time
Delivery speed stabilizes after 3-4 development cycles. Use historical delivery speed for forecasting, not wishful thinking.
3. Break Down Large Feature Requests
If you can't explain what a feature request delivers in one sentence, it's too big. Split it.
4. Include All Work in Delivery Speed
Code review, deployment, bug fixes — all of this is real work. Your delivery speed should reflect actual capacity, not just feature development.
5. Don't Game the System
Inflating estimates to look more productive is tempting and pointless. Delivery speed is for planning, not performance reviews.
The Bottom Line
Effort units aren't perfect. But they're better than the alternatives:
- Fixed-price contracts lead to corner-cutting
- Hourly billing incentivizes slowness
- "We'll tell you when it's done" provides no transparency
Effort units give stakeholders predictability, flexibility, and visibility into what their money is buying.
Want transparent project estimates? Get your effort unit estimate →
