How to estimate software projects with confidence
A step-by-step method for accurate, collaborative, and low-stress project forecasting.
If you work in software, it won’t be long before you're asked to estimate a new project - and the chances are, it’ll feel like being asked to stick a finger in the air to forecast next week’s weather. Even meteorologists struggle with that one - especially in the UK.
So, how can you confidently predict how long a project will take? Simply put: don’t overthink it.
Start Broad: Early-Stage Estimating
At pitch stage, you’re selling the dream - and should focus on the classic 20% that delivers 80% of the value. We usually fire up Miro, but Post-its, a notebook, or your favourite notes app will do just fine. Start by sketching out the essential components: things like ‘project setup’, ‘login and account management’, ‘product listing’, and so on.
Then, give each feature a T-shirt size or a Rough Order of Magnitude score. Don’t get too granular - starting at Large, or 1–2 weeks, gives you just enough of a broad brushstroke. Again, the key is a finger in the air = not on your chin.
Build Confidence Through Collaboration
If possible, get two engineers to estimate separately and compare their numbers. The magic comes from surfacing your assumptions (API quirks, legacy integrations, design sign-off) and speaking up if someone’s estimate feels wildly off. The figures may need further refinement during the pitch process, so it’s best to err on the side of generosity early on.
Move from Buckets to Breakdown
Assuming all goes well with the sales process, you’ll have a new client project in the pipeline. Well done! Now it’s time to swap those big buckets for fine-grained breakdowns. Split each feature into work packages - database schema, API endpoints, UI screens, and tests - and pin them up in your backlog or on Miro. Gather the team for a brisk round of planning poker: everyone picks a story-point card in secret, then reveals together.
Size What Matters: Using Story Points
Story points shift the conversation from “how many hours?” to “how complex and risky?” - helping balance out individual biases. For every story, write clear acceptance criteria (for example, “user can log in via OAuth, with an error shown on failure”) so that “done” really means done.
Pair up when estimating - one person reads the ticket, the other asks probing questions - and you’ll uncover hidden tasks before they catch you out. Build in a 10–20% buffer for inevitable design tweaks or blockers, and revisit your estimates at the end of each sprint or whenever the spec changes. Treat your numbers as living artefacts, not stone tablets.
A Few Best Practices
Visualise the project as a whole - ideally in diagram form - and spend some time making sure everything is captured. Triangulate your numbers by blending expert judgment, lessons from past projects, and simple parametric rules (for example, time per screen). Invite your CTO, product owner, or even the CEO into a short workshop to tap into their domain knowledge early. If you spot a glaring gap in someone’s estimate, raise your hand right away - delaying a call by five minutes is far better than under-delivering later.
Over time, track how your estimates compare to reality, and you’ll sharpen both your accuracy and your credibility.
From Blank Canvas to Roadmap
Estimating will always carry a touch of the unknown. But by starting with broad-brush ranges, then drilling into detailed tasks, relative sizing, and regular re-estimation for your MVP, you’ll turn that blank canvas into a reliable roadmap. Clear assumptions, paired-up estimates, and a little contingency will leave you and your stakeholders feeling informed and reassured.
Looking for something else?
Search over 400 blog posts from our team
Want to hear more?
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!
