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 […]
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 consists of two main components: (1) prioritizing backlog items and (2) agreeing on the number of backlog items in the sprint based on team capacity. Traditionally, (1) prioritizing backlog items is the responsibility of the product owner, whereas (2) deciding how much to pull in the sprint is the development team’s decision. Both should be a discussion with the entire team, while the responsibilities (and the final say) stay with the respective roles.
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.
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.
Daily Scrum Meeting
Daily scrum meeting is the third time box of Scrum. 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 mention any obstacles that may be in their way. The daily scrum meeting represents inspection and adaptation at a daily level. The Scrum delivery team members, product owner, and Scrum Master are participants in the meeting. Anyone else is welcome to attend but only as observers.
Sprint Review Meeting
The sprint review meeting is the fourth time-boxed event of Scrum. In this meeting, the work that the team has completed in the sprint is demonstrated and the progress of the team is assessed against the sprint goal. This meeting also provides an opportunity for stakeholders to give feedback about the emerging product in a collaborative setting. The delivery team, product owner, scrum master, and any interested stakeholders meet to review the features. They also talk about how the product is shaping up, which features may need to change, and even discuss new ideas that could be added to the product backlog. This meeting is time-boxed to four hours (for a 30-day sprint).
This is the final sprint meeting and the fifth time-boxed event of Scrum. 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 scrum master will take responsibility for any action items that the team does not feel it can handle and reports progress to the team regarding these obstacles in subsequent sprints. This meeting is time-boxed to three hours for a 30-day Sprint.
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 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. 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.
You might be interested in the following courses:
Course Category: Development Methodologies
A ScrumMaster must have a deep understanding of the Scrum framework. The job of a scrum master is to help the customer and the team to work very closely ensure expected deliveries. Scrum Master facilitates the team members to reflect upon ways that they can improve their day-to-day communication and processes. It is the responsibility […]
Agile Methodology refers to the software development methodology that is centered around the idea of iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The various Agile Methodologies share much of the same philosophy, many of the same characteristics and practices. But from an implementation standpoint, each of these methodologies has […]