Sprint Calculator

---

Purpose

As a project manager, you will often need to calculate how long a project will take to complete based on available data. Understanding the direct developer time is only one aspect, as there will always be additional meetings and ceremonies that must be accommodated. To this end, this Sprint Calculator spreadsheet allows you to fine tune the cadence of those ceremonies and see the overall impact on the timeline and costs of a given project. Meeting time is work time, and you should factor those in correctly and account for them in terms of costing.

Link

You can access the spreadsheet on Google Drive as a read-only template. Please go to File → Make a copy to use and edit your own version.

Usage

This Sprint Calculator is a working tool to help estimate how long a project might take, how many people you’ll need, and what it’s likely to cost. It assumes a sprint-based workflow and starts with the basics: how many working days are available in the year once holidays are accounted for, and how that translates into time available per sprint.

From there, it breaks things down into two main parts: time spent on actual development, and time spent on everything else that supports it — planning, standups, demos, retros. These are factored in automatically to give a more realistic view of how many hours of focused work can actually happen each sprint.

You then define the size of the project in hours and include a percentage buffer for feedback, fixes, or uncertainty. Based on this, the sheet works out how many sprints you’ll need and how that maps to the calendar. It also includes space to estimate deployment and testing time at the end.

Finally, there’s a cost breakdown. You can enter a mix of developer roles, each with their own day rate, and the sheet will calculate a blended rate and project cost. All of this is intended as a guide — not a commitment — but it should help you have clearer, earlier conversations about scope, time, and team size.

---

Detailed Breakdown

1. Calculate Days

• This section sets the foundation by working out how many days are available in the calendar year. It filters out weekends and public holidays to arrive at a count of true working days, then breaks those down into weeks, months, and average working patterns. These figures drive the rest of the calculations and help ensure the plan is based on realistic availability, not just idealised assumptions.

2. Calculate Ceremonies

• Agile ceremonies like planning sessions, standups, reviews, and retrospectives are essential, but they take time. This section estimates how many hours per sprint are likely to be spent in these shared routines. That time is then reserved from the total available hours so we don’t accidentally overcommit the development team.

3. Calculate Available Dev Hours

• Here we get to the practical output of the above: how many hours of focused development are available per sprint, after accounting for meetings and ceremonies. This includes time for planning and builds, giving a more grounded estimate of what a sprint can actually deliver. It’s especially useful for spotting if your team’s calendar is overloaded before you’ve even begun.

4. Calculate Sprints

• This section connects project scope to time. You enter the total number of estimated development hours, then apply a buffer for fixes and feedback. The calculator works out how many sprints are needed and maps those to calendar days, while also reserving time for user testing and deployment. It splits the project into “linear” and “non-linear” sprints to reflect the fact that some periods may be less predictable or more complex than others.

5. Calculate Dev Needs & Costs

• This section defines the shape and cost of your team. You enter how many developers you’ll need at each level — junior, mid, senior, and principal — and the sheet calculates the total team size along with a weighted average day rate based on their individual fees. This gives you a blended rate that reflects your actual team composition, which is then used in the fee and timeline calculations.

6. Calculate Fee

• Once time is mapped out, this section estimates the cost based on a blended day rate. You can adjust this rate or input more detailed breakdowns in the next section. The goal here is to provide a high-level view of the likely project cost, based on the team size and schedule calculated earlier.

7. Calculate Dates

• The final section converts sprint estimates into actual calendar dates. You set a starting point, and the sheet projects when development is likely to finish and when deployment should happen. These dates reflect the total number of calculated workdays, not calendar days, giving you a fair idea of delivery timing.

---