TL;DR: A sprint has a length the team already agreed, usually two weeks, and a start datetime that is a real calendar day. Stack later sprints by adding that length again, and keep demo day and release day as separate labels if they are not the same date. When kickoff slips, recompute on the weeks from today calculator; do not quietly shorten the sprint to “catch up.”
Length is a number in the working agreement
If the team agreed that a sprint is two weeks, the end is 14 days after the start, landing on the same weekday. You do not get to call a nine-day rush “sprint 14” and also claim the velocity chart is comparable. You can run a shorter cycle. You then name it as shorter and keep it out of the two-week series, or you accept that the chart will kink. The calculator’s role is modest: turn “two weeks from the kickoff day” into a date everyone can paste into the tracker. The social role — whether the team respects that date — is not something a date tool can repair.
Write the length where the dates are, not only in a charter nobody opens. “Sprint length: 2 weeks” at the top of the board prevents a well-meaning manager from treating the end date as a suggestion that moves whenever a demo room is free.
Two weeks from a Wednesday kickoff
Kickoff is Wednesday, 15 April 2026. Two weeks later is Wednesday, 29 April 2026. If your convention is that the sprint ends at the start of that Wednesday’s planning, say so: work days are 15 April through 28 April, and the 29th is the next kickoff. If your convention is that the 29th is still inside the sprint until close of business, the end is still the 29th but the next kickoff cannot also be the morning of the 29th. The week math does not choose the convention. It gives you the Wednesday. The team writes whether that Wednesday is a fence or a day of work.
A kickoff on Wednesday is slightly awkward for people who assume sprints start on Monday. Do not “fix” it by sliding the start back to Monday, 13 April unless the team actually started then. A Monday start plus two weeks is Monday, 27 April, which is a different end. Sliding the anchors to Mondays for neatness rewrites history and makes the demo invite wrong. Keep Wednesday if Wednesday is when you planned.
Three sprints in a row on one calendar
Using the fence convention “next kickoff equals this end,” the series from Wednesday, 15 April 2026 is:
- Sprint A: kickoff Wed 15 Apr 2026, next fence Wed 29 Apr 2026
- Sprint B: kickoff Wed 29 Apr 2026, next fence Wed 13 May 2026
- Sprint C: kickoff Wed 13 May 2026, next fence Wed 27 May 2026
Each step is two weeks. Sprint C’s fence is six weeks after 15 April, and six weeks after Wednesday, 15 April 2026 is indeed Wednesday, 27 May 2026. You can compute C directly or by stacking. Stacking is better when a middle sprint might change length, because a single six-week jump hides a one-week exception in sprint B. If B becomes three weeks, C’s kickoff moves to Wednesday, 20 May, and the old 13 May invite is wrong even though A did not change.
The demo and the release can fall on different days
Some teams demo on the last Thursday inside the sprint and release the following Monday, after a weekend of caution. For sprint A, last Thursday before the 29 April fence might be Thursday, 23 April 2026, and a release Monday might be Monday, 4 May 2026, which is not two weeks from kickoff. Those extra dates are offsets from the fence or from the demo, chosen for operational reasons. Label them. “Demo Thu 23 Apr (inside sprint A). Release Mon 4 May (not a sprint boundary).” If you tell a customer the release is “end of the sprint,” you have collapsed two dates into a phrase that points at 29 April. The customer will look for the build on the 29th. Either release then, or stop using the phrase.
A late kickoff does not shrink the two weeks
Planning finishes late and real kickoff moves from 15 April to Friday, 17 April. A full two-week sprint now fences on Friday, 1 May 2026. Keeping the old fence of 29 April creates a 12-day sprint. Sometimes you want that, to stay aligned with a release train that cannot move. Then say “sprint A shortened to end Wed 29 Apr; length is 12 days, not 2 weeks.” Sometimes you want the full length, and the train date moves. Then move the fence to 1 May and tell every invite. The failure is to do neither announcement and let half the team stop on the 29th while the other half codes through Friday.
Slack memory will not settle this. The ticket or the board header should show start, length, and fence in one line, edited the day the start changes. Comments below can argue about scope. The header holds the dates.
Leave the arithmetic where the work is tracked
Paste “Start Wed 15 Apr 2026 + 2 weeks = fence Wed 29 Apr 2026” into the sprint ticket. When someone proposes a new end, they edit that line and show the new addition. Recompute on the homepage if the mental math becomes a debate — debates about 14 days are a sign the channel is tired, not a sign the week is ambiguous. The next sprint’s start should be copied from this sprint’s fence, not retyped from memory a month later. That single copy-paste is what keeps A, B, and C from drifting apart by a day each cycle.
