Scrum Meetings are time-boxed events that may be facilitated by the ScrumMaster, though he or she does not have to be there and has no decision-making authority. However, the Scrum Master is expected to coach the team to follow the rules of Scrum at these meetings and throughout each Sprint.
Figure 3: Scrum Meetings
Sprint Planning Meeting
Part 1: At the beginning of each iteration, the Product Owner and Team negotiate which Product Backlog Items the Team will attempt this Sprint. The Product Owner is responsible for declaring which items are the most important to the business, and the Team is responsible for committing to the amount of work they feel they can accomplish without accruing technical debt.
Part 2: The Team decomposes the selected Product Backlog Items into an ordered plan of work, typically tasks, and makes a final commitment to the Sprint Goal. This plan is called the Sprint Backlog, and it represents the forecast of work needed to achieve the Goal as per the Definition of Done for a release-quality increment. The Product Owner’s full attendance is often not necessary during Part 2. The maximum time for planning a 30-day Sprint is 8 hours.
Every day, at the same time and place, the Scrum Development Team members spend 15 minutes refocusing their joint efforts on achieving the Sprint Goal. Each team member clarifies to the rest of the team what he did the previous day, what he will do today, and whatever impediments he or she may have. The Scrum Master is expected to mitigate any such impediments on behalf of the team.
The team will typically examine the current Sprint Task list, Sprint Burndown Chart, and impediments list.
The Product Owner’s attendance is often not necessary at the Daily Scrum and may actually impede team self-organization.
Topics that require additional discussion may be handled as optional sidebars after every team member has reported. It’s a common practice to stand at this meeting to create a sense of urgency, so it’s sometimes called the “standup meeting.”
Reporting to an entire team, rather than to a boss, is one of the new habits Scrum team members learn.
Sprint Review Meeting
At the end of each Sprint execution, the Team demonstrates the actual working product increment they built to the Product Owner, and other stakeholders invited at his or her discretion. Any undone work remaining from the Sprint Backlog is examined. Incomplete items are re-estimated and returned to the Product Backlog as candidates for future Sprints. Feedback from stakeholders may be converted to new Product Backlog Items.
The Sprint Review Meeting is an opportunity to inspect and adapt the product as it emerges and iteratively refine the understanding of the requirements. New products, particularly software products, are hard to visualize in a vacuum. Many customers need to be able to react to a piece of functioning software to discover what they actually want.
At the end of every Sprint, the team meets to reflect on its own process. They inspect their own behavior and take action to adapt it for future Sprints. This meeting provides an inspectand- adapt mechanism for the team’s process.
Techniques ScrumMasters can use to facilitate retrospectives3 include silent writing, timelines, satisfaction histograms, and many others. Common topics include: “What went well?”; “What could be improved?”; “What did we learn?”; “What still puzzles us?”; “What actions will we take?”
All Scrum Team members – that is to say, the Development Team, the Scrum Master, and the Product Owner – are expected to attend each Sprint Retrospective. Candid communication will help the team gain common understanding of multiple perspectives and come up with actions that will take the team to the next level.
Backlog Refinement Meeting
The team estimates the effort of items in the Product Backlog so the Product Owner can prioritize them before the next Sprint Planning Meeting. Large, vague items are split and clarified. New stories might be written by a subset of the team, in conjunction with the Product Owner and other stakeholders, before involving the entire team in estimation.
This meeting lacks an official name and is not a formal Scrum Event. It is an ongoing activity which may also be called “Backlog Maintenance,” “Backlog Grooming,” “Backlog Estimation Meeting,” etc.
Figure 4: Product Backlog
- Force-ranked list of desired functionality
- Visible to all stakeholders
- Any stakeholder (including team) can add items
- Constantly re-prioritized by Product Owner
- Items at top are more granular than items at bottom
- Maintained during Backlog Refinement Meeting
Product Backlog Item (PBI)
- Specifies the WHAT, not the HOW, of a customercentric feature.
- Often written in “User Story” form
- Has acceptance criteria (and/or product-wide definition of “done”) to prevent technical debt
- Effort is estimated by Team, ideally in relative units (e.g. story points)
- Business value is estimated by Product Owner
Figure 5: Each PBI represents a customer-centric feature, usually requiring several tasks to achieve definition of done.
Figure 6: Large PBIs (often called “epics”) split into thin vertical feature slices (“stories”), not horizontal implementation phases, when they rise toward the top of the Product Backlog.
Figure 7: The Sprint Backlog is often represented on an “information radiator” such as a physical task board.
A forecast of the PBIs needed to achieve the Sprint Goal, negotiated between Team and Product Owner during Sprint Planning
May flex during Sprint Execution in order to meet the team's Sprint Goal commitment
Visible to Team (primarily)
Referenced during Daily Scrum Meeting
Figure 8: The Sprint Backlog may also be represented electronically in a collaboration tool such as ScrumWorks® Pro. This tool’s electronic task board mimics the cards of a physical task board.
- Specifies “how” to achieve the PBIs’ “what”
- About one day or less of work
- Remainig effort re-estimated daily, typically in hours
- Task point person volunteers to see that it gets done, but commitment is owned by entire team and collaboration is expected
Figure 9: Sprint Burndown Chart
Sprint Burndown Chart
- Total remaining team task hours within one Sprint
- Re-estimated daily, thus may go up before going down
- Intended to facilitate team self-organization, not a management report
- Fancy variations, such as itemizing by point person, tend to reduce effectiveness at encouraging collaboration
Figure 10: A Release Burndown Chart variation popularized by Mike Cohn4. The red line tracks PBIs completed over time (velocity), while the blue line tracks new PBIs added (new scope discovery). The intersection projects release completion date from empirical data5.
Product/Release Burndown Chart
- Tracks remaining Product Backlog effort from one Sprint to the next
- May use relative units such as “Story Points” for Y axis
- Depicts empirical trends, introducing reality check to Product Owner’s release plan