Scrum Ceremonies #
The Sprint #
- a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created
- No changes are made that would endanger the Sprint Goal
- Quality goals do not decrease; and,
- The scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Sprint Planning #
Sprint Planning
Purpose: To answer the following question:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.
Scrum Masters Role:
Attendees: The Scrum team is required to attend sprint planning
Time & Location: Sprint Planning is at a set time, and location every sprint in order to reduce complexity for the team. It is an event for the Scrum Team (PO, SM & Dev Team).
Preparation:
- The input to this meeting is;
- the Product Backlog,
- the latest product Increment,
- the projected capacity of the Development Team during the Sprint,
- and past performance of the Development Team.
- The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
During Sprint Planning:
- The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment.
- Only the Development Team can assess what it can accomplish over the upcoming Sprint, given the capacity of the team after considering holidays and personal leave.
- Enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint.
- If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner.
- During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is 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. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.
- 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.
During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality goals do not decrease; and,
- The scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
- If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
Summary:
Daily Scrum #
Daily Scrum
Purpose: 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.
Scrum Masters Role: The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box
Attendees: The Daily Scrum is an internal meeting for the Development Team, all of whom are required to attend. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Time & Location: The Daily Scrum is held at the same time and place each day to reduce complexity. The Daily Scrum is held every day of the Sprint.
Preparation: Each development team member is expected to explain what they will do in the next 24 hours to move the team toward the sprint goal, and if or not they are experiencing any blockers or impediments with that work.
Summary:
Backlog Refinement #
Block Refinement
Purpose:
The purpose of Backlog refinement is to ensure that the Scrum Team has a prioritized backlog, with enough stories for at least the next sprint that can meet the definition of done. Many teams will choose to have 2-3 sprints of work ready, in case priorities change and something lower down the backlog needs to be implemented in the next sprint. Generally things further down the backlog are less “ready”.
In Backlog Refinement the team will add acceptance criteria to the stories possibly using BDD, and they can also size the stories that they believe can meet the definition of done. For those they believe are not ready, they can ask the Product Owner for more information, or potentially before the Sprint starts resolve issues with the other teams, technical issues, resolve complexities, or resolve any other penitential issues.
Any changes that affect risk will then require a Risk Self-evaluation questionnaire. If the results of the questionnaire show that another risk re-assessment template needs to be prepared and submitted, the Risk Assessor will produce the risk remediation recommendation based on the template. Because of the recommendation, risk-related user stories have to be created and be put onto the product backlog for future sprint delivery
Backlog Refinement is essential for effective Sprint Planning. In Sprint Planning there is much to get done to reach a sprint goal that the team is confident they can achieve. Having too few stories prepared before Sprint Planning starts will make sprint planning ineffective.
Attendees: The Scrum Team.
Time & Location: Backlog refinement is held once every Sprint. Ideally towards the middle of the Sprint giving the team time to resolve all issues with stories the Product Owner wants to bring into the next Sprint. The event takes between 1-2 hours.
Preparation:The Product Owner needs to ensure that a prioritized
Product Backlog has been prepared with enough stories for the team to work with.
Summary:
Sprint Review #
Sprint Review
Purpose: A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. 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.
Attendees: Required attendees include the Scrum Team, and other key stakeholders invited by the Product Owner may attend.
Time & Location: This will be one event for all teams, at a set time, and location every two weeks. It is held before the retrospective, and planning for the next sprint.
Preparation & Agenda (Each Attendee should be prepared according to their responsibility below:
- A “Done” increment is required at the Sprint Review.
- 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 Chief Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed); Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and, review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
- The each Scrum Team collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- The Chief Product Owner facilitates the event.
Summary:
Sprint Retrospective #
Sprint Retrospective
Purpose:
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; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work. An experiment will be brought into the next sprint.
Attendees: The required attendees at the Sprint Retrospective are: the Scrum Master, Product Owner, and the development team (ie the Scrum Team).
Time & Location: The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. In a scaled environment we will hold this event at the same time and location for all teams. Each team is given an hour for their retrospective, and time is then allocated for each team to share their experiment with the larger group.
Preparation:
- Scrum Master ensures the meeting is positive and productive.
- The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
- The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.
- 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.
- A representative from each team shares their experiment with the whole group.
- The Chief Scrum Master facilitates the event.
Summary:
Scrum Event | Frequency | Time | Duration | Teams/ People |
Scaled Daily Scrum | everyday | 0945-1000 | 15 mins | SP13 Team Lead Scrum Master Product owner Team Lead (join every Tue/ Thurs) Impacted IT teams (join every Tue / Thurs) |
POD Team Daily Scrum | everyday | 1015-1030 | 15 mins | SP13 Team Lead Team Lead Scrum Master Development team (Product owner) (Scrum Master) |
Scaled Backlog Refinement | 2nd week Wed/Thurs | 1430-1500 | 30 mins | Product owner Scrum Master SP13 Team Lead Team lead Impacted IT teams |
POD Backlog Refinement | 2nd week Tue/Wed/Thurs | TBC | 1.5 hours | SP13 Team Lead Team Lead Scrum master Development team (Product owner) (Scrum Master) |
Scaled Sprint Planning | Monday every 2 weeks | 0930-1000 | 30 mins | Scrum Master SP13 Team Lead Scrum Master SP13 Team Lead Product Owner Impacted IT Teams |
POD Sprint Planning | Monday every 2 weeks | 1000-1100 | 1 hour | SP13 Team Lead Team Lead Scrum master Development team (Product owner) (Scrum Master) |
Sprint Review | Friday every 2 weeks | 1500-1530 | 30 mins | Product owner Scrum Master SP13 Team Lead Scrum master Team lead Impacted IT teams Development team (User/Stakeholders) |
Scaled Retrospective | Friday every 2 weeks | 1530-1600 | 30 hours | Scrum Master SP13 Team Lead Scrum Master SP13 Team Lead Product Owner (Impacted IT Teams) |
POD Retrospective | Friday every 2 weeks | TBC | 1 hour | SP13 Team Lead Team Lead Scrum master Development team (Product owner) (Scrum Master) |