Scrum Meetings (or Scrum Ceremonies) are meetings that you're going to hold regularly to work within the Scrum Framework. The following are the typical Scrum Meetings that you will organise:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
The idea behind these meetings is to minimize the amount of time you spend in meetings and the amount of meetings that you actually need so that you can focus your time on delivering the products.
All these meetings should be time boxed. You should strive to stay within the time frame of the meeting.
In preparation for these meetings (and throughout working in the Scrum Framework) you will spend time refining the backlog items. This should take up no more than 10 percent of the Development Team's time capacity.
Sprint Planning is when the Scrum Team get together and plan the upcoming Sprint. This should take a maximum of eight hours for monthly Sprints.
Daily Scrum Meetings can last up to 15 mins at a time. This is where you can all catch up as a team to check on the progress of the current Sprint Goals and ensure that everything is on track. It is also a good time discuss any impediments that the team is facing.
The Sprint Review is used to inspect the outcome of the Sprint and determine future adaptations. This should take no more than four hours.
Finally, the Sprint Retrospective is used to plan ways to increase quality and effectiveness, learning from the previous Sprint and taking that knowledge into the next Sprint. This should take up to three hours.
These Scrum Meetings/Ceremonies should be all the meetings needed, although ad hoc get togethers for better communication are encouraged. The focus on these Scrum Meetings is on doing and delivering rather than meeting and documenting.
Using online resources, as well as the 2020 Scrum Guide, the following sections explain more about Scrum Events.
The Sprint
Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint, although some companies do have a "cool down" period in between scrums in order for the team to deal with technical debt.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality does not decrease;
- The Product Backlog is refined as needed; and,
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
As a Product Owner, you will need to understand what the requirements are and what is needed from the customer at that point in time. From that, you will decide what needs to be worked on during that Sprint as well as discussing with the Developers what is achievable within that time frame.
During the Sprint, a potentially releasable product feature is created. This can then be shown to customers and users to get feedback and help decide on the goal for the next 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.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows.
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint. If this is the case then any Increments made in the Sprint should be reviewed and used if applicable. A new Sprint Planning and new Sprint would start right away. Remember to discuss why the Sprint Goal became obsolete in the Sprint Retrospective and apply any improvements for the future.
Sprint Planning
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice such as key stakeholders but only when necessary.
Sprint Planning addresses the following topics:
---
Topic One: Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalised prior to the end of Sprint Planning.
In essence, the Product Owner is there to maximise value whilst the Developers discuss what can be achieved.
Topic Two: What can be 'Done' this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their definition of 'Done', the more confident they will be in their Sprint forecasts.
Topic Three: How will the chosen work get done?
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the definition of 'Done'. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
---
Sprint Planning meetings are organised and run by the Scrum Master. It is important for the Product Owner, along with the developers, to chose the right items to be worked on during the Sprint. The Product Owner needs to be up-to-date with what is needed from the product as they influence what gets done next. This can be done by having a 'Backlog Review' which involves looking at the backlog and making sure all items are as complete as possible. This allows you to go into the meeting prepared and make it as effective and efficient as possible.
The Product Owner can successfully influence the meeting using descriptors such as 'user stories', which are descriptions of features from an end-user perspective.
When categorising the amount of effort and time a specific feature or task will take, Developers will use 'story points' as estimations. Story points are normally scaled using the Fibonacci sequence (1, 2, 3, 5, 8, 13). The higher the number, the more difficult the effort, and the more time needed to complete that feature.
Daily Scrum
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. You will review what was and was not completed during the Sprint, host "show and tell" to the customer and stakeholders on what has been completed and how their environment will change following the end of the Sprint (progress towards the Product Goal is also discussed), and also to collaborate and discuss what needs to be done for the next Sprint. It is a good opportunity to understand from the customer or end user what is needed for the next release.
The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
Again, this meeting is organised and facilitated by the Scrum Master.
The Product Owner is looking to get:
- A sense of progress
- Clarity on what is needed from the next sprint
- Confirmation on satisfying customer requirements
- Ideas on how to refine the Product Backlog
The Developers will walk the attendees through the new features and changes.
Sprint Retrospective
The final meeting of the Sprint is the Sprint Retrospective. The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their definition of 'Done'. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Scrum Master will once again organise and facilitate this meeting. The idea is to keep the meeting positive and productive, have respect and empathy for your team and do no apportion blame. The main goal is to provide solutions to problems that were faced and outline how to improve.
