Sprint Timer

Set the sprint start date and length (one to four weeks), and the page shows days and hours remaining, the percentage of the sprint elapsed, and a progress bar, all recomputed from the calendar each time you open it. The numbers persist in this browser, so the same countdown greets you every morning until the sprint ends, at which point it rolls over to the next one if you have enabled that. Teams put it on a shared screen or a second monitor; individuals use it to keep a personal two-week goal in view.

• One week suits small teams with fast feedback and a lot of uncertainty. Planning and review overhead is proportionally high, so keep the ceremonies short.
• Two weeks is the most common length in Scrum teams: long enough to finish meaningful work, short enough that a wrong bet is cheap. Most agile guidance defaults to it.
• Three or four weeks suit work with long build or test cycles, hardware, or regulated environments. The risk is that a month feels like a project, and the end-of-sprint crunch returns.

Whatever the length, keep it fixed. The value of a sprint comes from the rhythm: the same review, retrospective and planning at the same time each cycle, so the team gets better at estimating what fits.

Time elapsed is not work completed. A sprint that is 50 % elapsed with 20 % of the work done is behind, and the timer's job is to make that visible early enough to act: drop scope, swap in smaller items, or ask for help on the blocked ticket. A common habit is to check the bar at the daily stand-up (the meeting timer keeps that to fifteen minutes) and to name the elapsed percentage out loud. Percentages that are said aloud get responded to.

For a countdown to a fixed release date rather than a rolling cycle, use the countdown. For focused work inside the sprint, the focus timer or the Pomodoro timer. For a team spread across offices, the world clock helps place the ceremonies where everyone is awake.