The 30-Day Sprint

Let’s look at how Sprints relate to Releases and what is involved in a Sprint. In this article, we will dive deeper into:

• Releases and Sprints
• Sprint Planning
• The SCRUM Meeting
• Sprint Reviews

A Release consists of multiple Sprints. The duration of a Sprint is 30 days. The number of Sprints in a Release may vary, depending on various factors like scope, but it is common to have three Sprints in a Release. At the end of a Release, working functionality is deployed on a Production Server. At the end of a Sprint, working functionality is demonstrated to the client.

Each SPRINT begins with a day dedicated to planning. On this day, all the functionality that needs to be built into the Sprint is decided. In other words, the Sprint Backlog is decided in the 1-day planning meeting. Some consider dedicating one complete day to planning as an administrative burden. However, if you assume 22 working days in Sprint, then 1 day in planning is less than 5%. This administrative overhead leads to increased team efficiency because the team knows exactly what is required from them in the Sprint. There is no risk caused by vague requirements, which can hinder progress. However, SCRUM does provide another tool, the SCRUM meeting, which helps the team gage progress and unearths risks on a daily basis.

The SCRUM meeting is held daily by the team. The meeting is usually less than 30 minutes. The team’s progress against the Sprint Backlog is checked. Any risks and issue are discussed. The SCRUM meeting ensures everyone is focused on the goal every day, until the date of delivering the SCRUM Backlog.

Each Sprint ends with a Sprint Review. During the Sprint Review the functionality built in the Sprint is demonstrated to the client. In turn,

click to enlarge

After all the Sprints in a Release have been completed, the functionality is deployed on a production server. The client can then begin gaining value from all the sprinting you and your team have been doing.