Agile estimates miss for three reasons: every product is built for the first time, the scope moves while you build, and people misjudge their own speed. You can’t remove any of the three. You can plan for them: estimate in ranges, re-estimate every sprint, and keep a forecast separate from a promise.
Estimation is also where many agile implementation challenges show up first. A team moves to sprints and backlogs, but the people paying still want one date and one price. This article covers seven estimation challenges, what AI coding tools changed in 2025 and 2026, and how to turn a forecast into a plan and a budget you can defend.
An estimate isn’t there to predict the future exactly. It does three useful jobs:
The third job matters most. A product that needs a year of work to earn a few hundred dollars a month is better killed in a spreadsheet than after six months of code.
Scrum treats the plan for a sprint as a forecast, not a contract. The Scrum Guide Expanded, updated in January 2026, calls the selected backlog items “the forecast” and expects the team to update its plan, even the forecast, during the sprint as it learns. Forecasting tools are welcome, it says, but they don’t replace learning from what the team actually delivers.
Most estimation problems fall into one of seven groups. The table shows how each one looks in a project and what helps.
| Challenge | What it looks like | What helps |
|---|---|---|
| 1. Uncertainty | Nobody has built this exact product before | Estimate in ranges; re-estimate after every sprint |
| 2. Incomplete requirements | “Users can pay” with no word on refunds, taxes or failed cards | Write user stories with acceptance criteria before sizing |
| 3. Complexity | A story that touches five systems gets the same size as a simple form | Split big stories; test the riskiest part first |
| 4. Limited resources | The plan assumes four developers, two are on another project | Plan on the people you actually have; recheck velocity when the team changes |
| 5. Time constraints | A launch date is fixed before the scope is | Fix the date, then cut scope to fit; never cut testing |
| 6. Scope creep | New “small” requests arrive every week | Put every request in the backlog and estimate it; something else moves down |
| 7. External factors | A payment provider, an outside API or app store review sets the pace | List outside dependencies at the start and test them early |
External factors are the easiest to forget. Take app store review. Apple says it reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. It also says more than 40% of unresolved issues come from guideline 2.1, app completeness: crashes, placeholder content and missing information (Apple). A rejection adds a fix, a new build and another review to your timeline.
AI coding tools are now part of most teams’ work, and they make estimates harder in a new way. Speed changes, and people are poor judges of the change.
In a 2025 randomized trial by METR, 16 experienced open-source developers worked on 246 real issues in projects they knew well. Before they started, they expected AI tools to make them 24% faster. Afterwards, they believed they had been 20% faster. Measured, they took 19% longer on the tasks where AI was allowed. METR calls this a snapshot of early-2025 tools in one setting and says the result is now out of date. The lesson for estimation still holds: how fast a team feels and how fast it is can point in opposite directions.
The 2025 DORA report from Google surveyed nearly 5,000 technology professionals. 90% of them use AI at work, and more than 80% believe it raised their productivity. DORA found AI use linked to higher delivery throughput but still linked to lower delivery stability, and 30% of respondents had little or no trust in AI-generated code (DORA 2025). Its summary: AI amplifies what a team already is.
What that means for estimates:
Think of ordering food. You ask for a large portion or a small one. You don’t ask for 400 grams of potatoes. You know a large is about twice a small, and that’s all you need to decide.
Relative estimation works the same way. The team doesn’t ask “how many hours is this story?” It asks “is this bigger or smaller than that one, and by how much?” Absolute estimation asks for hours or days up front.
Story points are a relative unit that combines the amount of work, its complexity and its risk. A 2-point story is about twice a 1-point story. Hours are absolute: the time one person expects to spend.
The trouble with hours is that they depend on who does the work. A task that takes a mid-level developer a day may take a senior specialist a few hours and a junior a week, with help from the rest of the team. Points stay the same whoever picks up the task, and velocity, the points finished per sprint, turns them into a forecast.
The trouble with points starts when someone converts them with a fixed rule, such as “two points equal one day”. That brings back every problem of hours and hides it behind a new unit. Our guide to story points and how to estimate them covers this in more detail.
Points and hours each have a job. Points plan sprints inside a team. Hours price work for the people who pay.
A common misunderstanding between clients and vendors is treating the first estimate as a promise. When this article first ran, Anastasiia Musil, a Scrum Master at Rocketech, put it simply: “When the team is just starting, we don’t know our speed yet.” The first estimate is a forecast. Each finished sprint makes the next forecast better.
Published prices work the same way. Across 95 agencies, the median published MVP starting price is $13,234 and the median promised timeline is 6 to 12 weeks (Rocketech MVP Price Index 2026, H2). Those are published prices, not what agencies charge after scoping. A firm price needs a written scope.
The fix is to match the contract to how much you know:
Hays is a good example of moving between these. The work started with a prototype to test the idea, then grew in iterations. As the tool grew, the project moved from a fixed price to a dedicated team to keep the work flexible.
You can’t remove uncertainty, but you can make every number in an estimate traceable. That’s how our project estimate works:
Here is an example run of our estimate’s math with sample inputs: an online store with a mobile app, a catalogue, a cart, checkout and an orders admin. The work items and the business numbers are assumptions. Only the arithmetic is ours.
| Phase | Hours |
|---|---|
| Discovery and UX: catalogue and checkout flows, wireframes | 15 |
| Design: UI kit and key screens | 18 |
| Frontend: store and app (catalogue, cart, checkout), admin for products and orders | 60 |
| Backend: catalogue, cart and orders, promotions and stock | 44 |
| Integrations: payments, delivery, email | 18 |
| QA: test plan and regression | 20 |
| Release | 6 |
| Total | 181 hours, a budget of $5,900-12,300, about 5 weeks |
The same run takes five guesses for the business side: a customer spends $45 a month, the margin is 35%, a customer buys for 10 months, winning one costs $25, and 200 new customers arrive each month. With those guesses, 68 customers pay for the build and it’s paid back in month 4. Every guess can be changed, and the math updates. Use the run to see which guess the whole plan depends on.
You can get a free project estimate for your own product and use it as the first forecast, then replace guesses with data as sprints finish.
Because every product is new, the scope changes as you learn, and people misjudge their own speed. Agile teams handle this by estimating in ranges, re-estimating every sprint and basing forecasts on finished work.
No. At the start it’s a forecast. The team commits to a sprint goal, and the forecast improves with each finished sprint. If you need a fixed price, fix the scope first, for example with a short discovery sprint.
Break the product into user stories, estimate the hours for each, and multiply by the rate to get a budget range. Once the team has finished a few sprints, switch to a forecast based on measured velocity.
Not automatically. A 2025 METR trial found experienced developers felt faster with AI tools but measured slower on their tasks, and the 2025 DORA report links AI use to more throughput but less stable delivery. Re-measure velocity after adopting new tools instead of cutting estimates up front.
Clients who want fixed numbers for moving scope, story points converted to hours with a fixed rule, scope creep without re-estimation, and plans that ignore outside dependencies. Each one has a fix: ranges, velocity, a visible backlog and early tests of the riskiest parts.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.