Picture this scenario. It is happening in boardrooms around the world right now.
An agency Project Manager is presenting a proposal to a client’s leadership team. The PM is excited about Agile. They have spent hours with their team playing “Planning Poker.”
The PM stands up and says: “Based on our analysis, this MVP is approximately 450 Story Points. We can deliver about 50 points per sprint.”
The client’s CEO looks confused. The CFO looks angry.
The CFO asks a simple question: “What is a point? And how much does one cost in dollars?”
The PM starts sweating. “Well, a point isn’t time. It’s a relative measure of complexity and risk. It depends on the team’s velocity, which we won’t know until we start…”
The CFO stops listening. The deal is dead.
This is what happens when you bring internal delivery tools into an external sales conversation.
Story Points are a fantastic tool for development teams. But they have absolutely no place in a sales proposal, a contract, or a client-facing budget discussion.
If you are trying to sell “points” to business clients, you are speaking the wrong language. This guide explains why this approach fails and how mature agencies bridge the gap between Agile delivery and business reality.
Table of Contents
- The fundamental divide: Delivery vs. Sales
- Why Story Points exist (The Internal View)
- Why clients hate buying “Points” (The External View)
- The contractual nightmare of relative estimation
- Your job is translation, not education
- Why devtimate deliberately banned Story Points
- Checklist
- FAQ
The fundamental divide: Delivery vs. Sales
The root of the confusion lies in failing to separate two distinct worlds within your agency:
World 1: Delivery (The Kitchen) This is where the software is cooked. It’s messy, complex, and requires specialized tools. In the kitchen, chefs talk about “mise en place,” temperature gradients, and relative effort. Story Points belong here.
World 2: Sales & Strategy (The Restaurant Table) This is where the customer sits. They don’t care how hard it was to chop the onions. They care about what is on the menu, how much it costs, and when it will arrive. Dollars and Dates belong here.
Many agencies make the mistake of inviting the client into the kitchen. They try to teach the client about Fibonacci sequences and velocity charts.
Clients do not want to learn how to cook. They want to buy a meal. When you force them to understand Story Points to buy from you, you are creating friction, not value.
Why Story Points exist (The Internal View)
To understand why points fail in sales, we must first respect why they exist in delivery.
Humans are terrible at estimating time absolutely (e.g., “This will take 4 hours”). We are much better at estimating relatively (e.g., “Task B is twice as big as Task A”).
Story Points were invented by the Agile community to:
- Abstract away time: To stop managers from treating estimates as blood oaths.
- Account for differences: A senior dev might do an “8-point” task in 4 hours, while a junior takes 12 hours. The complexity (the points) is the same, only the time differs.
- Measure Velocity: To track how much “complexity” a specific team can handle in a specific sprint.
Internally, for a stable team that worked together for months, Story Points are a brilliant mechanism for planning future sprints.
But notice the keywords: Internally. Stable team. Future planning. None of these apply to a new client proposal.
Why clients hate buying “Points” (The External View)
Now, put yourself in the shoes of the client’s CFO.
Their job is to manage risk and allocate capital. They deal in absolute realities: Budgets (money) and Deadlines (time).
When an agency presents a proposal in Story Points, the CFO hears:
1. “We are avoiding accountability.” By using an abstract unit that cannot be pinned down to a dollar value or a calendar date, it sounds like the agency is trying to hide. It feels slippery.
2. “We don’t know what we are doing.” Business leaders expect experts to be able to quantify their work in business terms. If you can’t translate your technical complexity into a budget and timeline, you don’t look like an expert; you look unprepared.
3. “I have no idea what I am buying.” If you buy 100 hours of development, you know roughly what you are getting. If you buy “100 points,” you have zero frame of reference. Is that a lot? Is that a little?
Clients pay real money for real outcomes delivered in real time. They do not pay for abstract complexity buckets.
- For more on the right units to use with clients, read our guide on Hours vs. Man-days.
The contractual nightmare of relative estimation
The biggest danger of using Story Points externally is when they end up in a contract.
A contract needs defined terms. “Dollars” are defined. “Calendar Days” are defined. “Story Points” are not defined.
Imagine signing a Fixed Price contract to deliver “300 Story Points for $100,000.”
Midway through the project, the client decides that a “Login Feature” (which your team estimated at 5 points) is actually much simpler and should only be 2 points. They want a refund for the difference.
How do you argue that legally? You can’t. A point has no objective value.
Or imagine the team changes. A new senior developer joins and the team’s velocity doubles. Does the client now pay half as much?
Writing Story Points into a Statement of Work (SOW) is a guarantee of future arguments. Contracts must be written in the universal language of business: scope deliverables, time, and money.
Your job is translation, not education
So, if your team uses points internally, but the client needs hours/dollars externally, what do you do?
You translate.
It is the agency’s job to build a bridge between the two worlds. You do not force the client to cross the bridge into your world.
The Professional Workflow:
- Internal Estimation (The Kitchen): Your team gets together and plays Planning Poker. They estimate the Work Breakdown Structure using Story Points. They debate complexity. This is healthy.
- The Translation Layer (The Bridge): The Project Manager or Tech Lead takes those points and, using historical data and experience, converts them into a range of hours.
- Example: “Historically, an 8-point story for this team takes between 20 and 30 man-hours.”
- External Presentation (The Restaurant): The proposal presented to the client contains only the translated output: hours, timelines, and budgets. The Story Points never leave the kitchen.
The client gets the clarity they need (budget), and the team gets the flexibility they need (relative estimation).
Why devtimate deliberately banned Story Points
When we built devtimate, we made a controversial product decision: We explicitly do not support Story Points.
We get asked about this constantly. It wasn’t an oversight. It was a deliberate choice based on the philosophy outlined in this article.
devtimate is a Sales and Estimation tool, not a Project Management tool like Jira or Asana.
- Jira is for Delivery: It manages sprints, velocity, and tickets. It needs Story Points.
- devtimate is for Commerce: It manages proposals, budgets, and contracts. It needs Hours, Days, and Dollars.
We believe that mixing these two worlds in a proposal tool is dangerous for agencies.
By forcing estimates in devtimate to be rooted in time (Hours) and capacity (Roles/Rates), we ensure that every proposal you generate is commercially viable and understandable by your clients’ business stakeholders.
We help you speak the language of the person signing the check, not the language of the person writing the code.
Start building commercially sound estimates with devtimate.
Checklist
✅ Never use the words “Story Points,” “Velocity,” or “Fibonacci” in a client-facing proposal.
✅ Use Story Points internally with your team if it helps them align on complexity.
✅ Designate a “Translator” (usually the PM or Tech Lead) whose job is to convert internal points into external hours/dollars before a quote goes out.
✅ Ensure your contracts always define scope in terms of deliverables and money, never points.
✅ Recognize that the client’s CFO is your ultimate audience for the financial part of the proposal; speak their language.
FAQ
1. But isn’t estimating in hours inaccurate?
Single-point estimation in hours (e.g., exactly “20 hours”) is inaccurate. That’s why professional agencies use ranges of hours (e.g., “20-30 hours”) based on optimistic and pessimistic scenarios. Hours, when presented as ranges, are the best tool we have for commercial estimation.
2. How do I convert points to hours if it’s a new team?
This is the hardest part. If you have no historical velocity data, Story Points are meaningless anyway. In this case, you are better off doing a traditional bottom-up estimate in hours using a detailed WBS and adding a significant risk buffer (the Cone of Uncertainty).
3. Doesn’t using hours violate Agile principles?
No. Agile is about embracing change and delivering value iteratively. It is not a religion that forbids the use of clocks or currency. You can have a fixed budget (in dollars) and a fixed timeline, and be Agile about what scope gets built within those constraints.
4. My client is tech-savvy and asks for Story Points. Should I give them?
Be careful. Even tech-savvy clients often misunderstand them when money is involved. If they insist, provide them for information only, but explicitly state in the contract that billing and deliverables are tied to money and scope, not points.
5. Why does devtimate feel strongly about this?
Because we have seen too many agencies get into legal and financial trouble by putting abstract concepts into binding contracts. Our mission is to help agencies be more profitable, and clear, commercial communication is the foundation of profitability.
Agile is a powerful methodology for building software, but it is a terrible methodology for selling it.
Keep your kitchen tools in the kitchen. When you walk out to present the menu to the client, leave the Story Points behind. Speak the language of business: time, money, and outcomes.
Use devtimate to ensure your proposals are always clear, commercial, and ready to be signed.
