I. Kickoff Meeting / Product Backlog Refinement
The purpose of the kickoff meeting is for you to get to know your fellow volunteers! This is an opportunity to share your skills, background, and goals.
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items (PBI). During PB refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done.
Higher ordered PBIs are usually clearer and more detailed than lower ordered ones. PBIs that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. PBIs usually acquire this degree of transparency through the above described refining activities.
The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
II. Sprint Planning
The entire Scrum Team will work together to plan the work to be performed in the Sprint at the Sprint Planning. The Scrum Master ensures that the event takes place and that attendants understand its purpose, keeping the meeting within the time-box.
Sprint Planning answers the following:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
During Sprint Planning the Scrum Team also crafts a Sprint Goal – an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment. Having set the Sprint Goal, the Development Team will select PBIs for the Sprint and decide how the team will build this functionality into a “Done” product Increment. PBIs selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Product Owner can help to clarify the selected PBIs and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected PBIs with the Product Owner.
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
III. Daily Scrum
During the Daily Scrum (aka Standups), the Development Team plans work for the next 24 hours. Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master ensures that the event takes place and that attendants understand its purpose, keeping the meeting within the time-box.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. Every day, the Development Team should understand how it intends to work together as a self- organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt / re-plan the rest of the Sprint’s work. The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
IV. Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. The Scrum Master ensures that the event takes place and that attendants understand its purpose, keeping the meeting within the time-box.
The Sprint Review includes the following elements:
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner.
- The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”.
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands.
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
V. Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. The Scrum Master ensures that the meeting is positive and productive, keeping the meeting within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools.
- Identify and order the major items that went well and potential improvements.
- Create a plan for implementing improvements to the way the Scrum Team does its work.
During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.
