Sprint
A sprint is a fixed time period (typically 1 to 4 weeks) during which a team commits to delivering a defined set of work. The sprint ends in a review (where the increment is demonstrated to stakeholders) and a retrospective (where the team reflects on its own process). It is used to create a predictable cadence of shipping working software and learning from it. It is the heartbeat of Scrum and the source of most of Scrum's value when run with discipline.
The structural rules that make sprints work: fixed length (sprints don't get extended; the work in flight at the end of the sprint either ships, gets rolled to the next sprint, or gets dropped), fixed scope mid-sprint (no new work added once the sprint starts; the protection of the team's focus is the whole point), all events run on schedule (planning at the start, daily scrum every day, review and retro at the end), and the team determines capacity (not the manager). Sprint length tradeoffs: 1-week sprints maximize responsiveness and create a relentless rhythm; useful for experimentation-heavy teams; the overhead of ceremonies as a percentage of total time is highest. 2-week sprints are the modern default, balancing rhythm with enough time to ship meaningful work. 3 to 4-week sprints allow more substantial work per cycle but slow feedback and concentrate planning load. The Scrum Guide (2020) explicitly caps sprints at one month; longer than that and the team has lost the responsiveness that motivates the framework. The most common deviation: teams that nominally run sprints but allow mid-sprint scope changes, undermining the entire point. If you can't protect the sprint from new scope, switch to Kanban, where continuous flow is the explicit model.
Ryan's Take
The sprint is one of the most useful inventions in modern product work when it's protected, and one of the most pointless when it isn't. The protection is the whole game. If your team's sprint is constantly interrupted by "urgent" scope changes from the founder or sales, you've stopped doing sprints and you're doing rolling status reports with extra ceremonies. The fix isn't more discipline in standups. It's an explicit agreement at the leadership level that the sprint is protected, with a separate channel (escalations, hotfixes, swing capacity) for the things that really can't wait two weeks. Without that agreement, sprints are just calendar decoration.
What founders get wrong: Letting "urgent" requests break the sprint over and over until the team gives up on the framework. Every interruption is the founder telling the team that their committed work doesn't matter. The cost shows up not in the missed sprint but in the cultural drift toward firefighting being the only real work.
Related: Scrum · Agile · Product Backlog · Kanban
FAQ
What is a sprint in Scrum?
A fixed time period (typically 1 to 4 weeks, with 2 weeks the most common) during which a team commits to delivering a defined set of work, ending in a sprint review and retrospective. Used to create a predictable cadence of shipping and learning. The Scrum Guide caps sprints at one month.
How long should a sprint be?
Two weeks is the modern default. 1-week sprints maximize responsiveness but concentrate ceremony overhead. 3 to 4-week sprints allow more substantial work per cycle but slow feedback. The 2020 Scrum Guide caps sprints at one month; beyond that, the responsiveness that motivates the framework is lost.
Can you add work to a sprint after it starts?
Strictly per Scrum, no. Mid-sprint scope changes break the protection of the team's focus, which is the whole point. If new work is genuinely urgent, the proper Scrum response is to cancel the current sprint and start over, which is rare. Teams that constantly add scope mid-sprint should switch to Kanban.
Find this article helpful?
This is just a small sample! Register to unlock our in-depth courses, hundreds of video courses, and a library of playbooks and articles to grow your startup fast. Let us Let us show you!
Submission confirms agreement to our Terms of Service and Privacy Policy.