Scrum events, activities or meetings
Scrum defines a series of regular Events, activities or meetings, each with their own specific purpose; this defines another set of constraints, to make sure that the Scrum Team sticks to the process and stays on the alert for signals of change. Having a rhythm to the work helps everybody sustain good practice, thus creating a culture in sync with the complex domain’s need for frequent inspections to set the course.
Meetings in Scrum are time-boxed for a couple of reasons. Without time-box control meetings tend to go on forever and become very unproductive; the slight pressure of the time-limit also helps retain focus and achieve a result, allowing people to move on to their real work. Every attendee then knows what to expect and can plan other activities accordingly. There has to be that slight sense of urgency.
The Scrum Master is present at all meetings and facilitates them.
Sprint Planning
Not surprisingly a Sprint starts by being planned. The Sprint Planning contains multiple elements: a set of PBI’s are chosen for the Sprint, decisions are made regarding execution of said PBI’s and a Sprint Goal is decided upon. For the sake of clarity we will go through the two consecutive parts of the Sprint Planning separately.
Sprint Planning 1
At the very beginning of the Sprint, the Team and the Product Owner meet to select the optimal set of Product Backlog Items for the Sprint in question. This is a time-boxed meeting, approximately 1 hour for each week of Sprint length.
Before entering the meeting the Product Owner has ordered and prioritized the Product Backlog and relevant items are declared ready by the PO and the Team (this includes an estimate of size of the work). The Product Owner has also formulated a proposed Sprint Goal, expressing the essence of what will be achieved in the Sprint. The Team has beforehand assessed their capacity and has a qualified estimate of the Velocity for the Sprint. So they have a pretty good idea of how much they can do.
The Product Owner presents the relevant items. If necessary more people with special insight are brought in. The Team asks questions, there is dialogue and a building up of common understanding. New knowledge may be harvested, estimates changed and prioritization may occur.
In the end, the best possible set of Product Backlog Items to implement in the coming Sprint is agreed and selected for the Sprint. At the end of this meeting we cross over from the strategic area to the tactical area, from “what to do” to “how to do it”.
Sprint Planning 2
The Team then continues on their own with the second half of the Sprint Planning; the PO is normally not part of the meeting but remains available for questions. Some Teams decide to include the PO in this second half as well. The meeting is time-boxed to about the same size as the first topic.
The Team now finalizes the analysis and design of each Product Backlog Item and breaks it down further into smaller pieces of work, typically formulated as Tasks. Tasks should take a maximum of one day to be finished.
If new questions or doubts arise, the Product Owner is called back to enlighten the Team further. The Team has assessed the items before, both in Sprint Planning topic 1 and in Product Backlog Refinement. If new knowledge is discovered, the selected Product Backlog Items may still change. The Team builds a Sprint Backlog of work to do.
When the meeting is over, we have a Sprint Goal, a Commitment – sometimes called a forecast – as to what the Team honestly believes it can deliver in the Sprint. The Team commits to do their best to accomplish this goal, a set of Product Backlog Items and a Sprint Goal. The Team also has a pretty good idea of how it is to be done. This is then made public as the Sprint Backlog.
Daily Scrum
During the Sprint, the Team and the Scrum Master meet every day, at the same place and time, to synchronize tactical activities and follow up on progress; it is an inspect-and-adapt meeting. This is called Daily Scrum. Everybody answers three questions:
- What have I accomplished since yesterday?
- What will I accomplish until tomorrow?
- Are there any impediments preventing my optimal work?
The Daily Scrum is time-boxed to 15 minutes and is public; people outside the Team can come; but they do not speak. If they have comments and questions they address the Scrum Master after the Daily Scrum.
During Daily Scrum the Team and the Scrum Master may discover the need for further discussions; extra meetings are quickly scheduled. Daily Scrum is not for finding solutions, just identifying needs.
The Scrum Master typically reports on his own work too. New impediments and obstacles are often recorded by the Scrum Master on the Impediment Backlog and immediately after Daily Scrum he addresses the issues.
Sprint Review
At the end of the Sprint, a Sprint Review meeting is held where the result of the Sprint is presented and feedback solicited. The result is called the Product Increment. The Team and the Product Owner are present, all stakeholders are invited. Everybody is encouraged to give feedback.
The Team has made sure that the PBIs presented are fully Done and the Product Owner can represent this to the stakeholders. In the unhappy event of the Stakeholders not agreeing that this is what they asked for, the PO records new Product Backlog Items describing the necessary corrections. New input and ideas may come up; the Product Owner records these for the Product Backlog.
It is common practice to discuss how the Sprint went, the Product Backlog as it stands and forecast about delivery times based on the acquired experience. In the same way new developments regarding users, the market, budgets etc are typically discussed in order to reach common understanding and provide the best possible input for the next Sprint Planning.
The Sprint Review is time-boxed with the recommended length being maximum one hour per week of the Sprint. It is however often kept on the short side (like 90 minutes) to accommodate other people in the organization with busy schedules. This meeting closes the PDSA loop with respect to the Product delivery. The Sprint Review is also an opportunity to collect input from diverse sources to help make sense of complex issues that often are beyond the range of the expert or specialist.
Sprint Retrospective
At the very end of the Sprint, the whole Scrum Team gets together to share experiences from the Sprint and reflect on potential improvements; this is called the Sprint Retrospective.
The meeting is time boxed to a maximum of 3 hours when using 4 week sprints. With shorter Sprints shorter meetings are used.
There are many forms of the Retrospective that can be chosen. What is important to achieve is:
- The Team and the Scrum Master share the facts of the experiences of the Sprint regarding people, relationships, process and tools.
- They reflect on the meaning of these experiences and pass judgment on what is positive and what could be improved.
- They prioritize what they want to improve and make a decision to act. What will the Team do, what will the Product Owner do and what will the Scrum Master do?
This meeting closes the PDSA loop with respect to how the work is being executed and the process followed. Again, the meeting is in line with the thinking of Cynefin. We recognize that this is more than a complicated expert domain. By letting the people involved self-assess, greater insight is achieved.
Product Backlog Refinement
There is yet another important activity, the Product Backlog Refinement. The Product Backlog needs to be thoroughly understood, prioritized and relevant items estimated before entering Sprint Planning. This is an activity involving the Product Owner and the Team. The Scrum Team decides how much time is needed in each Sprint for this activity.
To make sure this is indeed happening, it is often a good idea to institute one or more fixed events or meetings, typically held in the middle of the current Sprint with focus on the next Sprint and a bit more.
It is a preparation for the Sprint Planning meeting, so there are similarities in the typical agenda. The Product Owner and the Team are present. The Product Owner presents the items he has selected as candidates for the next Sprint along with new items that have surfaced or perhaps old items where circumstances for some reason or another have changed. Again there is dialogue and building up of common understanding.
The participants may break down large Product Backlog Items (often called Epics), refine descriptions, capture acceptance criteria and then estimate cost.
The difference between Product Backlog Refinement and a Sprint Planning 1 is that instead of selecting items, the items are clarified and estimated for cost (typically for size of work), risk and perhaps complexity. It is important that the estimation is performed by the people, who in the end will have to deliver – the Team.
Product Backlog Refinement is of great value to the Product Owner, as it enables him to improve the quality of his prioritization. The activity gives him the best possible understanding of the Items and an estimate of cost. After the Product Backlog Refinement the Product Owner still has time to prepare the prioritization for the next Sprint.
