Skip to main content
Methods

Sprint

A sprint is a fixed-length iteration (usually 2 weeks) in Scrum in which the development team delivers a defined set of work and a working software increment.

The sprint is the heart of Scrum and the rhythm of agile software development. In regular, equal-length iterations the team delivers working software – not someday, but every two weeks. That predictability gives stakeholders confidence and the team a clear rhythm. Each sprint is a mini-project with planning, execution, review and reflection.

What is Sprint?

A sprint is a time-boxed development cycle of fixed length, usually 1–4 weeks. During a sprint the Scrum team builds a potentially shippable product increment. The sprint has four events: Sprint Planning (what will we do and how?), Daily Scrum (daily 15-minute sync), Sprint Review (show outcome to stakeholders) and Sprint Retrospective (team reflection and process improvement). The sprint goal gives an overall direction. Once started, the sprint scope should not be changed – new work goes into the backlog for the next sprint.

How does Sprint work?

In Sprint Planning the team picks items from the Product Backlog and builds the Sprint Backlog with concrete tasks. Daily the team meets for the Daily Scrum: What did I do yesterday? What today? Any blockers? At the end the team shows the result in the Review – stakeholders give feedback that feeds into backlog prioritisation. In the Retrospective the team reflects: What went well? What can we improve? What will we change next sprint? Then the cycle repeats.

Practical Examples

1

Sprint 1 of an MVP: Login, registration and profile page – by the end a user can register and log in.

2

Feature sprint: The team implements cart functionality with product selection, quantity and price in one 2-week sprint.

3

Bug-fix sprint: After a release, critical bugs are prioritised and fixed in a focused sprint before new features.

4

Performance sprint: The team optimises load times, queries and caching – measurable improvement as the sprint goal.

Typical Use Cases

Product development: Delivering new features in predictable intervals and validating them

Client projects: Regular deliverables give clients transparency and control

Bug fixing and stabilisation: Focused sprints for quality after a release

Prototyping: Short (1-week) sprints for proof-of-concept and validation

Onboarding: New members learn the codebase and process within the sprint structure

Advantages and Disadvantages

Advantages

  • Predictability: Fixed timeboxes enable reliable forecasts for stakeholders
  • Regular feedback: Every 2 weeks stakeholders can review and steer
  • Focus: The team works on a clear set of tasks without new work mid-sprint
  • Measurability: Velocity (story points per sprint) makes team output visible and predictable
  • Learning: Every retrospective lets the team improve

Disadvantages

  • Sprint overhead: Planning, review and retrospective take time – with very short sprints overhead can dominate
  • Rigid scope: Urgent changes during the sprint are not planned for and can disrupt focus
  • Velocity pressure: Measuring output per sprint can create unhealthy pressure
  • Not for all work: Support, maintenance and ad-hoc work often fit Kanban better than sprints

Frequently Asked Questions about Sprint

How long should a sprint be?

Most teams use 2-week sprints – a good balance of predictability and feedback. 1-week sprints suit prototyping and very dynamic environments. 3–4 week sprints can fit complex topics but lengthen the feedback loop. Consistency matters: sprint length should not keep changing.

What if not everything is done by the end of the sprint?

Incomplete items go back to the Product Backlog and are reprioritised for the next sprint. That is normal in agile development, not failure. The important thing is to analyse in the Retrospective why the estimate was off and adjust future planning.

Can you cancel a sprint early?

Yes, but only the Product Owner can cancel – and only if the sprint goal has become obsolete (e.g. strategy or market change). Cancelling is an exception and should be rare. Done work is reviewed; incomplete work goes back to the backlog.

Related Terms

Want to use Sprint in your project?

We are happy to advise you on Sprint and find the optimal solution for your requirements. Benefit from our experience across over 200 projects.

Next Step

Questions about the topic? We're happy to help.

Our experts are available for in-depth conversations – no strings attached.

30 min strategy call – 100% free & non-binding

What is a Sprint? Agile Development Cycle Explained