The Scrum Sprint Life Cycle
Each scrum sprint has the same process — sprint planning, daily scrums, a sprint review, and a sprint retrospective. Sprints are developmental cycles that repeat until your project is complete. Requirements (often in the form of user stories) are developed, tested, integrated, and approved within each sprint. And the process continues sprint after sprint. The figure depicts a one-week sprint life cycle.
When scrum teams are distributed offshore with team members in faraway time zones (like US and India in this example), arrangements need to be made for all team members to attend each of the sprint meetings. To account for time zone differences, the domestic team members might join the meeting Sunday night while it’s Monday morning for the offshore team members. Then at the end of the sprint, the domestic team members finish the sprint Friday morning and take the rest of the day off while the offshore team is joining the sprint review and retrospective Friday night. Rotating each sprint might be appreciated on each end, so that each team member doesn’t always have to work on Sunday nights or Friday nights.
The key is that after each sprint, the scrum team learns new things. Change happens; it’s inevitable. Responding and adapting to it should be considered progress, not failure.
Change is easy in scrum, because at the end of every cycle what was created was done so to completion. When you go into your next sprint and work on items from the product backlog, it doesn’t matter whether those items have been on the product backlog for four months, four weeks, or four minutes. Old or new, each product backlog item gets prioritized not by the order in which it was received, but by the order in which it will deliver the highest value to the customer.
The Monday – Friday workweek is a natural, biorhythmic time frame. Whether one week or two, teams need the weekend break, and it fits naturally with life patterns. So avoid off-kilter sprint patterns of Wednesday – Tuesday or the like.