It sounds like a simple question: if your team uses effort units to estimate work, and you know what the team costs, can you calculate a price per effort unit?
People have been trying for over a decade. The answers range from $200 to $2,000 per point. Some agencies built entire business models around it. Government procurement departments wrote contracts based on it. And Ron Jeffries — the person who may have invented effort units — eventually said he wishes he hadn't.
This is the story of everyone who tried, what they learned, and why it remains one of the most debated topics in software development.
The Basic Math
The calculation itself is straightforward. Mike Cohn, founder of Mountain Goat Software and one of the most cited voices in agile estimation, describes it simply[1]: take your team's total cost and divide by the number of effort units delivered.
A team that costs $160,000 over 14 weeks and delivers 167 effort units has a cost per point of roughly $958. A team that costs $50,000 per development cycle and completes 25 points arrives at $2,000 per point. A cheaper team delivering more points might land at $200.
The math works. The problems start when you try to use the number.
Who Actually Tried It
PR 20/20: The Marketing Agency That Made It Work
The most successful implementation of point-based pricing didn't come from software at all. Paul Roetzer, founder of the marketing agency PR 20/20 (now ReadyNorth), spent over 600 hours building a service catalog before launching point-based pricing in January 2014[2].
His model assigned fixed point values to marketing deliverables — a blog post might be 3 points, a whitepaper 8 points — priced at $165 per point. Clients bought monthly point packages and could shift priorities without renegotiating contracts.
The key difference from software effort units: Roetzer's points measured deliverable value, not team-estimated complexity. A blog post was always 3 points regardless of who wrote it or how long it took. This removed the subjectivity that plagues software estimation.
Roetzer reported improvements in efficiency, productivity, and client transparency. Other marketing agencies adopted variations, with prices ranging from $165 to $175 per point[3].
The U.S. Government: Points-Based Procurement
In 2017, the General Services Administration's digital services team (18F) experimented with points-based procurement for their Agile Delivery Services contracts[4]. The idea was to buy team capability measured in effort units, allowing flexible, outcome-based contracts instead of rigid fixed-scope agreements.
A detailed analysis by Deloitte explored how points-based procurement could work in government IT[5], noting the appeal: agencies could buy delivery capacity without specifying every feature upfront.
The challenge was significant. Government procurement teams needed to understand delivery speed, feature request estimation, and development cycle mechanics — concepts foreign to traditional procurement. And effort units, being team-specific, made it difficult to compare bids from different vendors.
The Fixed-Price-Per-Point Contract
Christiaan Verwijs, writing for The Liberators on Medium, proposed a structured model[6]: set a fixed price per effort unit (he used $500 as an example) with minimum and maximum hour bands per point to share risk between client and supplier.
If the team finishes faster than expected, the supplier keeps the efficiency gain. If work takes longer, the client's exposure is capped. It was an elegant attempt to reconcile agile flexibility with contract certainty.
The model acknowledged a truth most effort-unit-pricing advocates avoid: the cost of an effort unit is not stable. It fluctuates with every development cycle, every team change, every shift in the codebase.
GData Software: The Transparency Argument
GData Software published a case for effort-unit-based cost estimation[7], arguing it was easier than time-based tracking. Their reasoning: when developers context-switch constantly and pair-program regularly, tracking exact hours per task is nearly impossible.
Their formula was simple: divide development cycle cost by points delivered. They framed the result as a transparency tool that builds trust between teams and stakeholders.
Why It Keeps Failing
For every company that tried effort unit pricing, there's a longer list of reasons why the broader industry rejected it.
The Creator's Regret
Ron Jeffries, co-creator of Extreme Programming and the person most commonly credited with inventing effort units, published a remarkable admission[8]: "I like to say that I may have invented effort units, and if I did, I'm sorry now."
His concern wasn't the concept of relative sizing itself, but what happened when organizations got hold of it. Management would focus on improving estimates rather than delivering value. Teams would game the numbers. The measure became the target.
His recommendation: drop effort units entirely where possible, and instead focus on slicing feature requests small enough for smooth delivery flow.
The Comparison Trap
Cohn himself identified the biggest danger[1]: once you calculate a cost per point, someone will compare teams. Team A costs $800 per point, Team B costs $1,200 — clearly Team A is more efficient, right?
Wrong. Effort units are team-specific by design. One team's 5-point feature request might be another team's 8-pointer. The delivery speeds of two teams are not comparable unless they've taken deliberate effort to establish and maintain a common baseline — and almost no one does.
Yet the temptation is irresistible. Management sees a number, and numbers demand comparison.
Gaming Is Inevitable
When effort units equal money, inflation follows. Accenture Federal Services published a piece titled "Stop Buying Effort Units"[9], warning that teams may intentionally inflate estimates to increase delivery speed — and therefore revenue.
The pattern is well-documented. Mountain Goat Software described cases where teams nearly doubled their delivery speed in months[10] — not because they got faster, but because estimates crept upward under management pressure. One Scrum Master reported a culture where "if you sneeze, you get an effort unit."
This isn't a bug in human nature. It's a predictable consequence of tying an internal planning tool to external financial incentives.
The Instability Problem
Discussions on the Scrum.org forums surface a fundamental mathematical issue[11]: effort unit costs fluctuate every development cycle. A team might complete 24 points in one development cycle and 37 in the next. The "price" of a point isn't fixed — it's a moving average at best.
Several forum participants called using effort units to calculate monetary costs a "gross misuse" of the concept. Effort units were designed for relative planning, not absolute pricing.
The Measurement Problem
Scott Logic published a detailed analysis[12] pointing out that effort units are ordinal categories of uncertainty, not continuous measures. Five points is roughly twice as uncertain as three points — not exactly 1.67 times. Pricing models that treat points as a linear continuum of pseudo-hours are mathematically misusing the scale.
The Fibonacci sequence exists precisely because precision decreases at higher magnitudes. Treating each point as worth the same dollar amount ignores this foundational design choice.
Hidden Work Disappears
Scrum.org analysis highlighted another flaw[11]: effort-unit pricing ignores all the work that doesn't get pointed. Architecture discussions, code review, DevOps, mentoring, bug triage, meetings — real work that consumes real cost but never shows up in delivery speed.
A team's effective cost per pointed feature request includes all this overhead. But the pricing model only sees the points, creating a systematic undercount of actual delivery cost.
What the Industry Chose Instead
The dominance of hourly and project-based pricing in the software services market tells its own story. Despite decades of agile adoption, most of the industry rejected effort unit pricing in favor of alternatives.
Time and Materials with Caps
The most common agile contract model: bill hourly or daily, with a maximum budget cap. The client gets flexibility; the supplier gets fair compensation; both share the risk of scope uncertainty.
Fixed-Capacity Development Cycles
Buy a dedicated team for a fixed number of development cycles. The scope within each development cycle remains flexible, but the cost is predictable. This is what most agile agencies and outsourcing firms actually sell.
Feature Request Counting
Martin Fowler documented an alternative that sidesteps the estimation debate entirely[13]: just count feature requests. His team at ThoughtWorks found that burn-up charts using feature request counts were essentially identical to those using effort units — because over time, teams naturally break work into similarly-sized pieces.
If all feature requests are roughly the same size, you don't need points at all. You need throughput: how many feature requests per development cycle.
Flow-Based Metrics
Modern engineering teams increasingly measure cycle time (how long work takes from start to finish), lead time (total time from request to delivery), and deployment frequency. These metrics connect directly to business outcomes without the abstraction layer of effort units.
Where Effort Unit Pricing Actually Works
Despite the problems, effort unit pricing works in narrow contexts:
Internal product decisions. Cohn's original use case is sound[1]: if your product owner knows a point costs roughly $2,000, a 10-point feature costs about $20,000. That helps with ROI decisions and feature queue prioritization — as long as the number stays internal and approximate.
Standardized deliverables. Roetzer's marketing model works because deliverables are repeatable and defined. A blog post is a blog post. Software features are rarely this uniform, but teams with highly standardized work (e.g., building similar CRUD interfaces repeatedly) can approximate it.
Budget forecasting. Using historical cost-per-point to forecast future project budgets is reasonable — if you treat the number as a rough estimate, not a contractual commitment.
The Fundamental Tension
Effort unit pricing sits at the intersection of competing needs:
- Sellers want predictability — fixed pricing makes sales easier
- Buyers want cost certainty — a known cost per unit feels safe
- Teams need flexibility — estimation requires room for learning and error
- Effort units are relative — they were never designed as an absolute currency
The fundamental problem is that effort units were designed as a team-internal planning tool, but pricing demands external, comparable, stable units of value. These requirements are incompatible.
Every attempt to bridge this gap either constrains the model so tightly that it loses agile flexibility (fixed-price-per-point contracts), or keeps it so loose that the "price" is meaningless as a commitment (internal-only forecasting).
What This Means for Your Project
If you're evaluating vendors who price by effort unit, ask these questions:
- How do they calibrate points? Without a reference baseline, the number is arbitrary.
- What happens when delivery speed changes? If the team slows down, does the cost per feature go up?
- What work isn't pointed? Architecture, code review, and DevOps cost money whether they're in the delivery speed count or not.
- How do they prevent inflation? If points equal revenue, the incentive to inflate is structural.
- Can you compare to other vendors? Unless teams use identical baselines (they don't), cross-vendor comparison on cost-per-point is meaningless.
The most honest approach is transparency: understand what the team costs, understand what they deliver, and evaluate whether the output justifies the investment — without pretending that a single number captures the full picture.
Want transparent, effort-unit-based project pricing? Get your estimate →
