A sprint is a fixed, time-boxed iteration in Scrum. The team selects a subset of the product backlog and aims to deliver a potentially releasable product increment by the end. Sprint planning, daily scrums, reviews, and retrospectives help the team plan, discuss progress, and adapt. section 7.1.2
Table 7.1 Scrum terminology (view table figure)
| Scrum term |
Definition |
|---|---|
| Sprint |
A fixed time-boxed iteration during which the team works on a subset of the product backlog, with the goal of delivering a potentially releasable product increment |
| Backlog |
A prioritized list of product features, enhancements, or fixes that the team works on during a sprint |
| Product owner |
The person responsible for managing the product backlog, prioritizing the work, and ensuring the team delivers value to the stakeholders |
| Scrum master |
The person responsible for ensuring that the team follows the Scrum process, removing any obstacles, and facilitating collaboration and communication |
| Sprint planning |
A meeting held at the beginning of each sprint during which the team reviews the product backlog, selects the items for the sprint backlog, and defines a sprint goal |
| Daily scrum |
A 15-minute time-boxed meeting during which the team members discuss their progress, identify any obstacles, and plan the work for the day |
| Sprint review |
A meeting held at the end of each sprint during which the team demonstrates the completed work to stakeholders and receives feedback |
| Sprint retrospective |
A meeting held at the end of each sprint during which the team reflects on their performance, identifies areas for improvement, and creates a plan for the next sprint |
| User story |
A short, simple description of a product feature from the perspective of a user or customer |
| Velocity |
A measure of the amount of work completed by the team during a sprint or over multiple sprints |
See the Scrum terminology table for the sprint definition and related terms such as backlog and product owner. section 7.1.2
Use sprints to make planned work manageable and create regular opportunities to inspect and adapt.
- To address technical debt, keep a prioritized list of mitigation tasks with effort estimates, then fit small tasks into lighter sprints. section 6.5.2
- For long-term technical debt, consider splitting developers between feature work and debt reduction, then switching their focus every two sprints. section 6.5.2
- A daily scrum alone does not make a team agile; skipping sprint reviews and retrospectives can undermine continuous improvement. section 7.1.2
Making room for technical debt
A team whose homegrown data-management component slows feature work might prioritize replacing it, estimate the work, and negotiate to schedule smaller mitigation tasks in lighter sprints. section 6.5.2
