Sprint Planning Template

Sprint Goals

• <A successful sprint requires sprint goals. Add them here. Goals may be inspired by retrospective items from the previous sprint, or by milestones that will be completed in this sprint>

Sprint Planning

• Finalize next sprint backlog.
• Add project issues.
• Add ad hoc/sustaining issues (BRING IN PERCENTAGE OF SUSTAINING).
• Planning with other teams
• Syseng
  • Any planned events?

• Validate commitment.
• Any DTO or other commitments that will lower velocity for the upcoming sprint?

• Any DTO on or around the next sprint planning (sprint after upcoming one)?
• If so, it is that person’s responsibility to plan for the next sprint with the scrummaster BEFORE the sprint ends.
• Any known unplanned work upcoming?
• How much unplanned work is anticipated. Use “yesterday’s weather”; how much unplanned work came up in the last sprint?
• Review and update release plan for current projects.
• Production support for this sprint is ____  (____  to shadow). Production support person accepts unplanned production blocking bugs during the sprint.
• Production support for last sprint was __% time.
• Scrummaster for this sprint is _____.

Backlog grooming

• The team performs backlog grooming continuously through the sprint.
  • All issues for each project in progress have an estimation. Each project’s issues and release schedule are estimated.
  • All issues that will come into the next sprint have requirements and acceptance criteria.
  • All issues have non-functional requirements, such as performance profiling and logging, considered.
  • All projects should have complete user stories for the next sprint.
• Additionally, there is a team backlog grooming meeting to ensure the top of backlog is in shape for the next sprint.
• All issues likely to begin work in the next few sprints are moved from LABENG to LABENGDTC.
• Review ad hoc/sustaining epic report to make sure time spent in this area is as expected.
• Team understands all stories for the upcoming sprint. Team is OK committing to the work in the stories.

Pencils down

• The beginning of the sprint review/demo is “pencils down”.
• Only code that is reviewed, committed/merged to master is demoed and called “done”.
• For all finished issue
• Data and code is updated in all environments.
• Code review is done
• Code is committed to version control.
• Issues in any other state are unfinished and move to the next sprint or backlog.

Sprint review/demo

• For each finished issues, demonstrate all acceptance criteria.
• What is demoed is releasable--could be released to production immediately if desired.
• Capture feedback and enter into backlog.
• For production issues
• To mark a production issue “done”, there should be a set of bugs or stories that improve or resolve the issue. These issues should be reviewed as the demo.
• Close all finished issues in last sprint.
• Move unfinished issues to new sprint or backlog.
• Observe velocity of last sprint.
  
• Update release tags
• For issues done during this sprint, update the release tag with the planned release date.
• For the current week’s release, update the release tags for all issues (did we release what we thought we would?). “Release” the release in jira.
• For issues that will move to the next sprint, update the release tag with the new projected release date.
• Identify the scrummaster for the following sprint.
• Close sprint, moving unfinished issues to the next sprint or backlog.

Retrospective

The sprint retrospective is an opportunity to improve the development experience for the team. There are three goals for the retrospective:

1. Celebrate successes.
2. Identify opportunities to improve.
3. Commit to action to improve on the opportunities during the next sprint.

• What went well?
• How did we take advantage of opportunities identified in previous sprint’s retrospective?
• What are opportunities for improvement?
• Based on those opportunities, what are we committing to do in the next sprint to improve the experience?
• Scrummaster for the next sprint is ____ .