How are the end dates calculated?

Each sprint runs for the chosen number of weeks. The end date is the last day of the sprint — that is, the start plus (length × 7 − 1) days — and the next sprint starts the following day with no gap.

What sprint lengths are supported?

Any whole number of weeks from 1 to 12, and from 1 to 52 sprints, which covers the one-, two-, and three-week cadences used by most Scrum and agile teams.

Does it skip weekends or holidays?

No. Sprints run as continuous calendar blocks, so a two-week sprint is exactly 14 calendar days. End dates can therefore land on weekends; adjust ceremonies separately if needed.

Why does a two-week sprint end 13 days after it starts?

Because the start day itself counts as day one. A 14-day sprint occupies days 1 to 14, so the last day is 13 days after the first, and the next sprint begins on day 15.

What date format does it use?

Dates are shown using your browser's locale with a weekday, day, month, and year, so the format matches your regional settings automatically.

Is any data sent anywhere?

No. The schedule is generated entirely in your browser and nothing is uploaded.

What is the Sprint Date Calculator?

Free agile sprint date calculator — enter a first sprint start date, sprint length and number of sprints to generate a back-to-back schedule of start and end dates. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Sprint Date Calculator

Name: Sprint Date Calculator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Plan an agile cadence in seconds. Enter your first sprint start date, the sprint length in weeks, and the number of sprints, and this tool generates a back-to-back schedule of start and end dates — handy for release planning, roadmaps, and filling in a team calendar.

How it works

The schedule is built as a chain of fixed-length calendar blocks:

Sprint length in days = weeks × 7.
First sprint starts on your chosen date and ends on start + (length − 1) days, because the start day itself is day one.
Each next sprint begins exactly length days after the previous start, so sprints sit directly back to back with no gaps or overlaps.

Inputs are validated: 1–12 weeks per sprint and 1–52 sprints. There is no weekend or holiday skipping — these are continuous calendar spans.

Worked example — quarterly roadmap

First start Monday 1 September 2026, 2-week sprints, 6 sprints:

Sprint	Start	End	Working days
1	Mon 1 Sep	Sun 14 Sep	10
2	Mon 15 Sep	Sun 28 Sep	10
3	Mon 29 Sep	Sun 12 Oct	10
4	Mon 13 Oct	Sun 26 Oct	10
5	Mon 27 Oct	Sun 9 Nov	10
6	Mon 10 Nov	Sun 23 Nov	10

The six-sprint quarter runs from 1 September through 23 November — useful for setting a Q4 release candidate date and working backward to feature-freeze sprint boundaries.

When to use which cadence

Length	Common use case
1 week	Rapid experimentation, tight-feedback startups
2 weeks	Most Scrum teams — balances planning overhead with iteration speed
3 weeks	Larger features, hardware-software integration, or regulated environments
4 weeks	Traditional Kanban milestones or programs with monthly release trains

The two-week sprint is by far the most common in software teams. If you are planning a PI (Program Increment) under SAFe, run 5 two-week sprints followed by a one-week Innovation and Planning sprint; you can model the 5 sprints here and add the IP week manually.

Tips for building a reliable schedule

Choose your sprint start day deliberately. Starting on Monday keeps the sprint boundary on Sunday, which means retrospectives fall naturally on a Friday and planning on the next Monday. Starting on Wednesday can fragment long weekends.

End dates land on weekends in a standard two-week sprint beginning Monday — the last calendar day is Sunday. Sprint ceremonies (review, retro, planning) should be scheduled for the preceding Friday and the following Monday rather than the official end date.

Build in capacity buffers for known holidays. The calculator uses raw calendar days, so a sprint spanning a public holiday still shows 10 working days but actually has only 9 available. Flag those sprints in your roadmap and reduce their committed scope accordingly.

Export to your calendar tool. Copy the table, then create recurring calendar events for planning and review by matching the sprint boundaries from this schedule. Most project management tools (Jira, Linear, Shortcut) let you set a sprint start date and duration rather than entering individual dates — just seed the first sprint and let the tool chain the rest.