Sprints

The iteration phase is divided into short periods called sprints. A sprint is typically 2 weeks long, equivalent to 10 working days. It's a short burst of work focused with short-term goals in mind.

Typical schedule

• Day 1: Sprint planning (Wednesday)
  This is a meeting between the whole team where the stakeholders and leads decide on what features to build for the sprint.

• Day 7 to 10: QA pass
  This is when the QA team starts testing finished features.

• Day 9 to 10: Feature freeze
  This is the bug fixing period. Developers stop working on new features and focus on fixing bugs that were reported by QA, new or old.

• Day 11: Release (Wednesday)
  The first official release happens after a sprint finishes. For web projects, this means deploying your project to production. This coincides with next sprint's day 1.

This is just a sample template; other projects may have longer or shorter QA and feature-freeze days than this, or may not have either at all (not recommended).

Never Monday or Friday

It's recommended to start sprints on Wednesday. It can be any day, as long as it's not Monday or Friday.

• A sprint can't end on a Friday. If something goes wrong on the final release deployment on a Friday, no developers would be around to fix things on the weekend.
• Fridays are not a good time to start a sprint, either. People may be too tired to be effective at planning.
• Holidays often fall on Mondays or Fridays, so scheduling releases on Tuesdays helps make things consistent despite holiday schedules.

The final deliverable

The final result of a sprint is a release. It should be a polished, production-ready product to the best of your efforts. Anything incomplete should be removed from the release, and anything almost-complete should be wrapped up before the sprint is over.

Next: Let's learn how to plan sprints.