Successful Scrum implementations involve a handful of important sprint events (also called sprint meetings or sprint ceremonies. This includes meetings such as sprint planning, sprint review, daily scrum, sprint retrospective, and more.
There’s often confusion about who participates, when these events are conducted, how long each takes, the purpose of each event, and more.
To reduce the confusion, we’ve created infographics that answer each of these questions for sprints of 1-, 2-, 3- and 4-weeks.
Sprint Planning
The sprint planning event marks the official start of the sprint. Once this event starts, so has the sprint.
The Scrum Master, product owner, and developers (development team) all participate. Others may attend on rare occasions when the product owner and team both agree it’s appropriate.
For example, if the coming sprint will include developing functionality best explained by a subject matter expert (who is not the product owner), it can be useful to have that person attend. Usually, however, that type of discussion is best conducted outside the actual planning meeting.
The length of the sprint planning ceremony is proportional to the length of the sprint. A four-week sprint should be planned in no more than 8 hours. A one-week sprint should be planned in no more than two hours.
These are time boxes (maximums). I recommend teams target completing sprint planning in about half the allowable time box.
As input into sprint planning, the Scrum Master will bring data on the team’s average velocity and most recent velocity. The product owner will bring the product backlog, or at least the highest priority items on the product backlog. On many teams, the product owner will also supply a draft sprint goal, which may be collaboratively revised through the planning process.
The outputs of sprint planning include a team that is smarter about and better prepared for the upcoming work. Additional outputs include a sprint backlog and an agreed upon sprint goal.
Daily Scrum
The daily scrum, also known as the daily standup, is a short 15-minute timebox during which team members synchronize effort each day. Daily scrums enable team members to ensure the right things are being worked on by the right people at the right time.
Each day, each participant addresses three topics:
- What did I do yesterday to help achieve the sprint goal?
- What will I do today to achieve the sprint goal?
- What, if anything is impeding or blocking progress toward the sprint goal?
Questions can be phrased in any number of ways. For example, many teams find it beneficial for participants to describe what was accomplished rather than what they did.
Participants include the Scrum Master, development team, and, in my opinion, the product owner.
There is some debate within the Scrum community about whether the product owner should participate. Excusing the product owner from the daily scrum creates a separation within the overall team. Us-and-them feelings exist already in too many organizations. I don’t know why a Scrum team or its product owner would want to do anything to further enhance that negative attitude.
Each daily scrum is limited to 15 minutes. The intent is for it to be a brief update and synchronization effort.
Unlike sprint planning, I don’t recommend trying to complete a daily scrum in half the recommended timebox. For most teams, 5-7 minutes is simply not enough time to raise any real issues or understand the work being accomplished. When teams shorten the daily scrums too much, the ceremony devolves into a series of rote updates, such as “Yesterday I did such-and-such. Today I’ll do this-and-that. Nothing is in my way.”
There are no formal inputs to the daily scrum. The only output is increased coordination of the developers' work.
Sprint Review
The sprint review event happens on the last day of the sprint. It should be attended by the product owner, Scrum Master, the development team and any appropriate stakeholders. The stakeholder participants may vary from sprint to sprint based on what has been delivered.
The sprint review is time boxed to a maximum of four hours for a four-week sprint. It is proportionately shorter for shorter sprints, down to one hour for a one-week sprint.
As input to the sprint review, the team should show all of the product backlog items that meet the team’s definition of done. This means that the team does not show work that is still in process. Sometimes, however, it may be worth making an exception to this rule.
The demo of finished functionality is the central activity of a typical sprint review. But most teams will also take time to discuss progress and problems. You can read about my recommended agenda for the sprint review.
The goal of the review is to solicit feedback on what was built during the sprint. The product owner considers all feedback and can make changes to the product backlog as appropriate. The output of a sprint review is therefore a revised product backlog.
Sprint Retrospective
The sprint retrospective event is a time for team members to consider how to improve their way of working. This means they may change aspects of how they do Scrum, such as the length of their sprints.
But a retrospective can also cover general aspects of working together, such as whether to ban morning meetings or which topics are appropriate to discuss on Slack and which require a face-to-face conversation.
The sprint retrospective should be attended by the whole team—including the Scrum Master and the product owner. To do otherwise is create a schism within the team. A good agile team should avoid any behavior that leads to an us/them mindset.
There are no formal inputs to a sprint retrospective other than a willingness to improve. The output is a list of changes the team will make to how it works. Some teams formalize this list as an improvement backlog.
The sprint retrospective is formally timeboxed to 3 hours. A retrospective may occasionally take that long but most teams will conduct most retrospectives within an hour.
Product Backlog Refinement
Product backlog refinement refers to ensuring the items at the top of the product backlog are ready for the next sprint. This can include adding detail to existing items, estimating, deleting items, adjusting priorities, splitting product backlog items (or user stories) so as to better fit within a sprint, and creating new items.
While product backlog refinement itself is necessary, it is not mandatory that a team do refinement as a formal ceremony or that it be done every sprint. Most teams will, however, conduct regular product backlog refinement meetings, usually once per sprint or once per week.
Usual guidance is to spend no more than 10% of a team’s total available time on product backlog refinement both in meetings and in discussions that may result from those meetings.
Most teams will have the entire team participate (including the product owner and Scrum Master). Unless a team will be estimating product backlog items during its refinement meetings, I find that perhaps half to two-thirds of the development is sufficient and reduces the overall meeting time burden on a team.
The only inputs to this ceremony are the items at the top of the product backlog. Outputs are product backlog items that are often split to be smaller and better fit within a sprint as well as greater understanding of some product backlog items.
Backlog Estimating
As noted above, many teams will estimate during product backlog refinement meetings. That is the ideal approach, and is possible if the entire development team participates in backlog refinement.
If only a subset of the development team participates in backlog refinement, team members will meet once per sprint to estimate any new work for which the product owner may need an estimate.
For most teams, these estimating events should be very short. Most teams should not generate or receive a flood of new product backlog items each sprint. Work to be estimated should either be important, new product backlog items or existing items that have been split to better fit in the coming sprint.
I like to do product backlog estimating immediately following a daily scrum, a couple of days before the end of the sprint. That is late enough that most new items will have been identified but in time for the product owner to adjust priorities based on the new information conveyed by the estimates.
I do not recommend estimating during sprint planning. That is too late for the product owner to adjust priorities based on the estimates. It also leads to team members spending longer than they should on estimating. So, don’t estimate product backlog items during sprint planning.
Prioritization
Before a new sprint begins, the product owner ensures the top of the product backlog has been prioritized. According the Oxford American Dictionary, prioritize means “to put tasks, problems, etc. in order of importance, so that you can deal with the most important first.”
This means it is not sufficient for a prioritization to merely say, “They’re all required.” Or, as one product owner told me, “They’re called requirements for a reason—they’re required.”
In most cases, there will not be an official prioritization meeting or ceremony. Rather, this is something the product owner does alone, often following conversations with stakeholders to understand their needs and desires.
Prioritization should happen as late as possible in the sprint, while making sure it’s done before the next sprint. This will often mean doing it on the last day or two of the sprint.
Usually prioritization is not time consuming. This is because the product owner is typically fine-tuning priorities based on progress and learning from the current sprint rather than performing an outright re-prioritization of an entire product backlog.
When Do You Conduct These Events?
When does your team conduct these events? Are there other events you’d recommend other teams do? Are your participants the same as I’ve described? Please share your thoughts in the comments below.
