There’re officially 5 events in Scrum:
- The Sprint - container for all the other events.
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
All Scrum Events are timeboxed. They all have set a maximal timebox. They enable us to apply the three Scrum pillars.
- Transparency
- Inspection
- Adaptation
All the events, aside from the Sprint, are opportunities to inspect and adapt something. All 5 events are mandatory. We are not allowed to skip any of them in a scrum project.
Time-boxing
It’s all about having a maximum duration of the event, that you cannot cross.
All these events in Scrum repeat. The whole purpose here is to help you stay focused. Each event has its specific goal, being limited in time increases the focus of the members involved. Besides the Sprint, they can finish sooner than the deadline of the event, providing the goal has been achieved.
The Sprint has a set duration and this cannot be changed forth and back, but it can be changed if we think it would suit the team best to have 3 weeks Sprints instead of 2.
When a project is risky, we would choose to do shorter Sprints because we want to receive feedback faster.
The Sprint
Sprints are the heartbeat of Scrum, where ideas are turned into value. Think of one Sprint as one iteration. During the Sprint we create an increment that contains all previous increments.
All other events, happen within the Sprint. The Sprint itself, is a container for all other events. Nothing happens between Sprints. The Sprint cannot be longer than one month.
The Scrum Team chooses the duration of the Sprint. You cannot change the Sprint duration, while you’re in the middle of the Sprint.
If the Sprint ends and there’re still days left, the Developers come to an agreement with the Product Owner and may, for example, move items from the Product Backlog to the Sprint Backlog.
We don’t have special technical Sprints in Scrum such as Sprint Zero.
If the Sprint goal becomes obsolete, only the Product Owner has the authority to cancel a Sprint. He might do it under the influence of the customer, the developers or the Scrum Master, but the other roles cannot do it by themselves. Cancelling a Sprint is always bad for the team.
Sprint Planning
This event is about planning the work, that needs to be performed during the Sprint. We plan what we want to build. The Sprint Planning is timeboxed to a maximum of eight hours, for a one month Sprint.
The entire Scrum Team attends this event. Not just the Developers.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items.
The Sprint Planning addresses 3 questions:
- Why is this Sprint valuable?
- What can be Done this Sprint?
- How will the chosen work get done?
The whole Scrum Team defines the Sprint Goal. The Sprint Goal also must be finalized prior to the end of the Sprint Planning.
The Sprint Planning is the part, where developers select items from the top of the Product Backlog, along the Product Owner. They make a forecast of the items they can complete.
Product Backlog Refinement is an Event so the Developers can have a good understanding of the items. This can happen at any time. Also during Sprint Planning. The result of this Event are stories that are ready for development.
To make good forecasts, the developers should take into consideration its past performance, their upcoming capacity, and their Definition of Done.
When you enter the Sprint Planning, we’ve created the Sprint Backlog. The Sprint Backlog consists of the Sprint Goal, the Stories and the plan to deliver these Stories.
Daily Scrum
The general purpose it’s to inspect progress towards the Sprint Goal and adapt the Sprint Backlog if needed. It’s about inspection and adaptation. During Daily Scrum the Developers plan the work for the next day.
This event is mandatory for the Developers, but the Product Owner and the Scrum Master can attend as well. If the PO or the SM are actively working on items in the Sprint Backlog, they participate as developers. (remember one person can have more than one role.)
The SM makes sure it takes place, is positive and happens within the time box, but the Developers conduct it.
This is the only event that always takes 15 minutes, no matter the length of the Sprint. It’s held and takes place at the same place, same time to reduce complexity.
Developers can choose whatever structure and techniques they want as long as the event focuses on progress towards the Sprint Goal, and produces an actionable plan for the next day of work.
The Daily Scrum is not about removing impediments, it’s about identifying them.
Sprint Review
This is second to last event inside a Sprint. (the last is the Retro). The main purpose for the Sprint Review is to inspect and adapt. We inspect the outcome of the Sprint. What they’ve built. It will review the increment in the context of both, Sprint Goal and Product Goal.
The Sprint Review is a 4 hour event for a 1 month Sprint.
The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. Both The Scrum Team and key stakeholders attend this event.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. 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.
We only present items that are 100% done. Never half done items. This is because we might become wrong feedback.
Sprint Retrospective
The Sprint Retro happens after the Sprint Review and before the next Sprint Planning. Its main purpose it’s to plan ways to increase quality and effectiveness. We inspect the processes the team used to build the increment. This event is about the context, and not the content.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools and their Definition of Done. 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 Sprint Retrospective is mandatory. Sprint Retro is a 3-hour event for a 1-month Sprint.