Sprints are the scheduled expense of time against commitments made by the team that the product owner anticipates and understands.
- PM - continues planning for the next sprint; attending to story development by working with team members to ensure questions are identified and converted into requirements, or working with the product owner to resolve questions and prioritize the backlog.
- Designer - create comps and assets required for the stories in the current or next sprint.
- Engineer - execute a technical solution against stories, verifying they satisfy requirements.
- QA - verify the technical solution matches comps and satisfies the requirements of the stories.
Sprints are typically 2 weeks and should aim to fit the right amount of stories for each team member such that meetings, planning and bug fix time are accounted for. Other sprint elements (in chronological order) are: sprint planning meeting, daily standup, sprint demo, and sprint retrospective.
The basic unit of measure for a sprint is the number of stories planned vs complete. This ratio indicates team velocity and should be used to modulate the time valuation of story points.
If a story is not tested during the sprint then it is not complete. Incomplete stories go to the top of the backlog when the sprint ends, despite being in progress. If the sprint ends with too many open bugs against new features, the project will begin incurring a problematic technical debt. This usually requires drastic reduction in the number of stories accepted into the subsequent sprint.
- paying a previous technical debt
- unclear requirements
- failing to test ones own work
The cause of not completing stories should be discussed and understood during the sprint retrospective.