When a developer tells you they work in sprints, they are describing a specific way of organizing and delivering software work. Understanding what a sprint is, what happens during one, and what you should expect from a team that runs them well helps you work more effectively with any development team.
The core idea
A sprint is a fixed period of time, typically two weeks, during which a team commits to completing a specific set of work. At the start of the sprint, the team selects tasks from a prioritized list. At the end, they deliver those completed tasks and demonstrate the results.
The sprint model comes from Scrum, which is the most widely used agile framework. Scrum defines specific roles (Product Owner, Scrum Master, Development Team), specific meetings (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective), and specific artifacts (Product Backlog, Sprint Backlog, Increment).
Most teams take the useful parts of Scrum (the fixed-length iteration, the demo, the retrospective) and adapt the rest to fit their context. The label "sprint" has become general enough that it just means "a fixed-length work period with a defined scope and a demo at the end."
What happens during a sprint
Sprint planning (day 1): The team reviews the top items in the backlog and selects what they can complete in the sprint. Selections are based on the team's velocity (how much work they typically complete per sprint) and the priority set by the product owner or client.
Each selected item should have acceptance criteria before it is committed. If the team does not know how to define "done" for a task, it should not be in the sprint.
Daily standup: A brief daily check-in (typically 15 minutes) where each developer answers three questions: what did I do yesterday, what am I doing today, and is anything blocking me? This is a coordination mechanism, not a status report. It surfaces blockers early rather than discovering them at the end of the sprint.
The work: Developers build the features committed in sprint planning. They run automated tests. They code review each other's work. They resolve blockers through the standup or through direct communication.
Sprint review (final day): The team demonstrates completed work to stakeholders. This is the most valuable meeting in the sprint cycle for a client. You see working software. You provide feedback. The team captures that feedback for future sprints.
Sprint retrospective: The team reflects on how the sprint went. What went well? What did not? What should change next sprint? This is an internal team meeting but its outcomes affect your project's efficiency over time.
What you should see as a client
At the end of every sprint, you should see a demo of working features. Not slides. Not mockups. Working features in a staging environment.
The demo should cover everything the team committed to in sprint planning. If items were not completed, the team should explain why and what the plan is for the remaining work.
You should be able to provide feedback on the demo. That feedback either goes into the current sprint if there is remaining time and it is a bug, or into the backlog for prioritization in a future sprint if it is a new feature or change.
What goes wrong with sprints
Commitment overload. Teams that consistently commit more than they can complete in a sprint are operating without a realistic understanding of their capacity. The result is incomplete sprints, which provides false visibility into progress.
Sprint theater. Teams that have the meetings and the terminology but do not actually produce working software at the end of each sprint are performing agile without practicing it. If you have attended six sprint demos and have not seen fully working features, that is a problem.
Skipped retrospectives. Teams that do not do retrospectives do not improve. The retrospective is the mechanism by which the team gets better over time. A team that skips retrospectives is not invested in improving its process.
Client unavailability. Sprints depend on fast client feedback and decision-making. A client who is unavailable to review demos, answer questions, or approve decisions creates bottlenecks that cascade through sprint delivery. If you are the client, being responsive is not optional.
What two weeks of sprints costs in a typical engagement
For planning purposes: a two-developer team running two-week sprints delivers work at a pace you can track and predict.
After three sprints, you have a reliable sense of what the team completes per sprint. This velocity allows reasonable forecasting of when specific features will be ready.
The predictability of sprint-based delivery is one of its main advantages over waterfall development, where you often do not know how far behind you are until near the end of the project.
See how our development process works before engaging a team. Get in touch to discuss sprint-based delivery for your specific project.