Brief review of the Scrum framework

Scrum is simple; it consists of six time boxes (one of which is optional), three roles, and three 'official' artifacts.

A sprint, the first of the six time boxes, is an iteration defined by a fixed start and end date; it is kicked off by sprint planning and concluded by the sprint review and retrospective. The team meets daily, in a daily scrum meeting, to make their work visible to each other and synchronize based on what they've learned.

Sprint planning

During sprint planning, the second time-boxed event, the product owner and the team discuss the highest priority items in the product backlog and brainstorm a plan to implement those items. The set of chosen product backlog items and their subsequent tasks collectively is referred to as the team's sprint backlog.

The sprint planning meeting is time-boxed to eight hours for a 30-day sprint, reduced proportionally for shorter sprints (for a two-week sprint, for example, one may reduce that time to a maximum of four hours). The meeting is comprised of two parts. The first segment of the meeting is driven by the product owner who presents the most important product backlog items—along with any helpful drawings, models, and mockups, for example—and clarifies questions from the development team about what he/she wants and why he/she wants it. The second segment of the meeting is driven by the Scrum delivery team who work together to brainstorm approaches and eventually agree on a plan. It's at the start of this second segment that the sprint actually begins.

Of course, teams are always searching for ways to make planning faster and more efficient. You will likely see sprint planning take less time over a number of sprints for a team whose members have remained consistent.

The result of sprint planning is a sprint backlog that is comprised of selected product backlog items for the sprint, along with the correlating tasks identified by the team in the second segment of sprint planning. We'll discuss many details and ideas for effective sprint planning meetings in Chapter 3, Sprint Planning – Fine-tune the Sprint Commitment

Daily scrum meeting

In the daily scrum meeting, the third time box of Scrum, team members make their progress visible so that they can inspect and adapt toward meeting their goals, sort of like a mini-Deming (PDCA) cycle every day! The meeting is held at the same time and in the same place, decided upon by the team. Even though a team makes its best attempt at planning for a sprint, things can change in flight. Tom finishes a task late, Beth finishes early, Ashish is stuck. In this 15-minute meeting, team members discuss what they did since yesterday's meeting, what they plan to do by tomorrow's meeting, and to mention any obstacles that may be in their way. The role of the ScrumMaster in the daily scrum is to facilitate, keep the conversation from delving into problem solving, and record any obstacles that team members feel they cannot fix for themselves. The ScrumMaster will attempt to remove said obstacles after the meeting. The daily scrum meeting represents inspection and adaptation at a daily level. The Scrum delivery team members, product owner, and ScrumMaster are participants in the meeting. Anyone else is welcome to attend but only as observers.

Sprint review meeting

The sprint review, the fourth time-boxed event of Scrum, provides the opportunity for stakeholders to give feedback about the emerging product in a collaborative setting. In this meeting, the team, product owner, ScrumMaster, and any interested stakeholders meet to review the features and talk about how the product is shaping up, which features may need to change, and perhaps discuss new ideas to add to the product backlog. It is common for a ScrumMaster to summarize the events of the sprint, any major obstacles that the team ran into, decisions that were made in-flight with the product owner's help, and so on, and of course the team should always demo what they've accomplished by the sprint's end. This meeting is time-boxed to four hours (for a 30-day sprint).

Sprint retrospective

During the final sprint meeting— the sprint retrospective—team members discuss the events of the sprint, identify what worked well for them, what didn't work so well, and take on action items for any changes that they'd like to make for the next sprint. The ScrumMaster will take on any actions that the team does not feel it can handle; likely broader organizational issues. The ScrumMaster reports progress to the team regarding these obstacles in subsequent sprints. This meeting is time-boxed to three hours. We will dive into more details about sprint reviews and retrospectives in Chapter 5, The End? Improving Product and Process One Bite at a Time.

Release planning (optional)

The final time box in Scrum is release planning, an optional event, in which Scrum teams plan for long-term initiatives comprised of multiple sprints' worth of work. The product owner and team discuss product backlog items, dependencies, risks, schedule, and capacity, among other topics, in this meeting to settle on a forecast for upcoming work. Since the product backlog can be infinite, release planning helps the team and product owner understand what may be possible given a release deadline. This subset of the product backlog is called the release backlog and is a valuable output of the release planning meeting. Release planning should be time-boxed but the time required depends upon the scale of the program, the number of teams, team distribution, and how well the product backlog is prepared. Release planning meetings are often held at the beginning of the project, and teams will meet with their product owners throughout the project to re-plan based on emergent knowledge. It is not unheard of, however, for teams to postpone planning a release until they have a few sprints of work under their belts, as the experience and knowledge they gain in a few sprints results in greater confidence in a longer-term release plan (more details in Chapter 2, Release Planning – Tuning Product Development). Either approach is acceptable and depends upon the needs of the organization.

Ken Schwaber once said to me, "I don't know why people make this such a long, drawn-out event. It isn't really that hard." And with that, we completed our release planning in 15 minutes.