Sprint
A fixed-length iteration (typically one to four weeks) in Scrum methodology during which a team commits to completing a defined set of work items and delivering a potentially shippable increment.
A sprint begins with sprint planning (selecting work items from the backlog), includes daily standups for coordination, and ends with a sprint review (demonstrating completed work) and sprint retrospective (reflecting on process improvements). Each sprint should produce a potentially releasable product increment.
For QA teams, sprints create a structured testing rhythm. Testing is not a phase at the end of the sprint but an ongoing activity throughout. Stories should meet the Definition of Done, including testing, before being considered complete. QA engineers participate in planning to assess testability and estimate testing effort.
Why It Matters for QA Teams
Sprints create time pressure that can tempt teams to cut testing corners. QA teams must advocate for testing time during sprint planning and ensure the Definition of Done includes adequate quality verification.
Example
In a two-week sprint, the team plans to deliver a new user dashboard. During planning, the QA engineer flags that the dashboard includes a real-time data widget that will need cross-browser testing and performance validation. The team adjusts the sprint scope to include two days of dedicated testing time and adds specific acceptance criteria for performance thresholds.