Use this tag for questions related to a "Sprint", which is a time box used for iterative/incremental development in Scrum. The term is also used by various other agile frameworks that have borrowed the term from Scrum, and is currently considered on-topic for non-Scrum frameworks that use the term for planning or time boxing even if the specific implementation details vary.
A Sprint is a fixed length time box that establishes a cadence for Scrum, and supports Scrum's incremental and iterative approach to development. The term is now commonly used by other agile frameworks such as SAFe, although implementation details may differ.
Please add any other on-topic frameworks or methodologies here that explicitly use "Sprint" within the site's meaning of the term.
Note: This section may be outdated, as portions do not align with the 2020 Scrum Guide.
A sprint is the basic unit of development in Scrum. Sprints last between one week and one month, and are a "timeboxed" (i.e. restricted to a specific duration) effort of a constant length.
Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.
During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is a prioritized list of requirements. Which backlog items go into the sprint (the sprint goals) is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog.
The sprint backlog is property of the development team, i.e. during a sprint, no one is allowed to edit the sprint backlog except for the development team. The sprint goals should not be changed during the sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog.
After a sprint is completed, the team demonstrates how to use the software.