Hearing some confusion about the team (Scrum) events is almost a daily occurrence. Therefore, I wanted to summarise in my own words what events are defined in Scrum and the expectation in each of them. As a reminder there is always the scrum guide to fall back on.
To begin with, Scrum has an assumption that teams have a Product that they are working on. Each Product has a Product Owner, who has a Product Goal, which defined why the product exists, what is the problem that its solving, and for whom? Work needed to achieve the Product Goal is collected into a Product Backlog, which is an ordered list of items that the Developer will work through to achieve the Product Goal. The order of this list is that in which the team should deliver work, to deliver the maximum value, and is defined by the Product Owner.
The first event, which is not part of the Scrum Guide anymore, is Backlog Refinement. If any of the Product Backlog Items in the Product Backlog do not contain enough detail for the team to even start working on them, then the team set up the refinement session with the Product Owner (who may also include relevant stakeholders) to provide additional details and remove uncertainties. The refined PBI will have acceptance criteria and enough detail that the developers can start working on them.
Given the Product Backlog is in place, then the first event for the team is Sprint Planning. The team take Product Backlog Items from the top Product Backlog, working with the Product Owner, the developers begin to understand what is the most valuable next thing to implement. Through Sprint Planning the most valuable PBIs are taken from the Product Backlog, broken down into smaller tasks and planned. Through this process the Product Owner and Developer formulate a Sprint Goal (singular) which acts as a North Star during the sprint, expressing why the work is valuable. During the planning process the developers are constructing a plan for how the work will be completed and verify that they have the capacity within the team to do so. By the end of planning the team will have a plan for what work will be completed (the Sprint Backlog), how they will work together as a team to deliver the work, and have an understanding of why this work is valuable. The team commits to the Sprint Goal (not a set of tasks or stories), and the work begins.
As the work progresses the team meets Daily. It is important to note that this is not a status or update meeting. It’s not about answering the three questions. It is not a problem-solving session. It’s not the time for code reviews or design discussions, these can happen afterward. The Daily (scrum) is a fifteen-minute timeboxed event where the team can identify any problems and re-plan their work for the next day in order to give them the best opportunity of meeting the Sprint Goal. Any problem-solving or discussions can happen after the Daily Scrum, allowing those not involved with the issues to return to their activities. The daily (scrum) is for the team to synchronize on their delivery activities, and is why swarming (the whole team working together on backlog items) is such an important part of scrum. If the team is a collection of individuals working on loosely related tasks they will see little benefit from the Daily.
At the end of the Sprint we review the Product Increment in the Sprint Review. This is more than just a demo. It is a chance for the Product Owner to talk to Stakeholders about future plans, add to, and reorder the Product Backlog based on Stakeholder feedback, changing market conditions, or things that have been learnt during that last Sprint. The Sprint Review is about inspecting the Product and highlighting improvements, which will form new Product Backlog Items which get added to the Product Backlog.
The final event of the Sprint is our Sprint Retrospective. In the Sprint Review we examine the Product and how that can be improved. In the retrospective we examine the team’s ways of working. This includes the way they collaborate, team processes and procedures. They can examine their Definition of Done, or anything else where there is room for improvement. Having visualised an improved way or working the team should define concrete action items that take them a step towards this new way of working. Ideally, metrics can be defined for review later and to show improvement.
During the Sprint the Product Owner will be updating the Product Backlog, creating new
PBIs and reordering the Product Backlog as more is learnt. There will also be additional Backlog
Refinement sessions where Product Backlog Items near the top of the Product Backlog are fleshed
out so that by the time they are pulled into a Sprint all the relevant information needed by the
team is available.