Essentially, a Sprint is a time-boxed period – usually 2-4 weeks long – during which a specific objective must be reached. The goal is to have a deliverable product or product component at the end of each Sprint. Multiple Sprints are grouped into releases, and releases are grouped into epics as you move up the Agile portfolio management ladder.
Consistently effective Sprints are vital to the success of your Agile portfolio. It makes sense, then, to spend some time discovering how to plan for successful Sprints . As is the case with most Agile processes, the initial planning focuses on setting up a structured, sustainable system that can be used repeatedly to achieve desired result.
Phase One: Designing
Designing the Sprint is a one-time process that can be tweaked for continuous improvement going forward but should not have to be completely repeated unless the design in use has proved unreliable.
The basic components of designing a Sprint are fairly standard, although how each component is handled, measured, and reported on will differ between organizations and teams:
• Sprint Planning Meeting – where portfolio business initiatives are estimated and the initial Sprint backlog is created.
• Task Breakdown Meeting (usually part of the Sprint Planning Meeting) – where tasks are created and estimated and the Sprint backlog is finalized.
• Daily Scrum Meeting – where progress of the Sprint is reviewed with the team on a daily basis and tasks are prioritized and assigned based on review of the Sprint burndown chart.
• Backlog Grooming – throughout the Sprint, the product owner and team review, refine, and fill gaps in the product backlog based on progress made.
• Sprint Review Meeting – where the results of a completed Sprint are analyzed in comparison to the objective(s) established at the Sprint Planning Meeting.
• Sprint Retrospective Meeting – where the processes and tools used during the Sprint are reviewed by the team with an eye on improvements during the next Sprint.
In designing Sprints for the organization, the focus is on establishing a reasonable schedule of activities (including those necessary items listed above) along with milestones the team should be aiming for throughout the Sprint period.
The Sprint design should receive organizational consensus since it is the basis of planning at the higher levels of Agile portfolio management. For example, the length of each Sprint will determine the overall release cadence and, in the longer term, the amount of productive work (and therefore profit) that can be expected during a given period of time.
Phase Two: Estimate Sprint Velocity
Before each Sprint, the program manager and product owner must estimate the velocity of the Sprint (how much can and should be accomplished within the time box) based on team schedules and capacity.
By creating this estimate at the beginning of each Sprint rather than universally during the design stage, they can take advantage of valuable insights coming out of the previous Sprint’s retrospective and review meetings. Ultimately, creating a new Sprint velocity that accomplishes the necessary objectives efficiently with the resources on hand.
Phase Three: Allocate Work to the Sprint
Using the established Sprint velocity estimate and other requirements provided by the product owner, the Scrum Master then works with the team directly to allocate work to each new Sprint.
By allowing the team itself to function autonomously during phase three, one of the key benefits of Agile development can shine: the self-directed Agile team organizes itself for each Sprint matching the necessary work with the most effective team members to handle those tasks. Not only does this mean the right people will be doing the right things during the Sprint, but the team members will feel a higher level of accountability for successfully completing these tasks since they were empowered to assign them out as a team.
With these three phases of Sprint planning complete, each Sprint has the best chance of moving forward successfully.