Who Should Attend Scrum Meetings?

I am frequently asked who should attend the various Scrum meetings—sprint planning, daily scrums, sprint review, sprint retrospective, and product backlog grooming. My Essential Scrum book provides detailed answers to all of these questions. However, after numerous requests, I have decided to summarize my answers in this blog post. 

Terminology

Let me begin by defining the terms I will be using to refer to potential attendees. Scrum development efforts consist of one or more Scrum teams, each made up of three Scrum roles: product owner, ScrumMaster, and the development team. 

There can be other roles when using Scrum, but the Scrum framework requires only these three. In this blog I will focus on which of these three roles should be present at each of the Scrum meetings and why. When I use the term “Scrum team” I will be referring to all three roles as a triad—meaning the development team, the ScrumMaster, and the product owner are all participating.

Sprint Planning

The full Scrum team collaborates during sprint planning. The product owner shares the initial sprint goal, presents the prioritized product backlog, and answers any questions the team might have regarding product backlog items. The development team works diligently to determine what it can deliver and then makes a realistic commitment at the end of sprint planning. The ScrumMaster, acting as the Scrum team coach, observes the planning activity, asks probing questions, and facilitates to help ensure a successful result.

Exactly when the product owner role participates in sprint planning depends on your approach.

You can read more about sprint planning in Chapter 19 of Essential Scrum.

Two-part Sprint Planning

One approach is to split sprint planning into two parts. During part 1 (the what part) the development team determines its capacity to complete work and then forecasts the product backlog items that it believes it can deliver by the end of the sprint. So if the team believes it can accomplish 40 story points, it will select about 40 story points’ worth of work. During part 1, all three Scrum team roles are present the entire time.

During part 2 (the how part) the team acquires confidence in its ability to complete the items that it forecasted in part 1 by creating a plan. Most teams create this plan by breaking the product backlog items into a set of tasks and then estimating (in hours) the effort required to complete each task. The team then compares the estimate of task hours against its capacity, in terms of hours, to see if its initial commitment was realistic.

At the start of part 2 the product owner leaves the room, leaving behind the development team and the ScrumMaster so they can perform the acquire confidence activity (e.g., task breakdown). At the end of part 2 the product owner rejoins the development team and ScrumMaster so the development team can either confirm: “Yes we can deliver what we told you in part 1” or “No, we can’t give you want we said in part 1, but here is what we can give you.”

One-part Sprint Planning

An alternative approach to sprint planning is a one-part approach that interleaves selecting an item and acquiring confidence that it can be delivered. Using this approach, the development team begins by determining its capacity to complete work. Next the team selects a product backlog item and then acquires confidence that the selected item will reasonably fit within the sprint, given other items already included in the team’s evolving commitment. This cycle is then repeated until the team is out of capacity to do any more work. At that point the commitment is finalized and sprint planning is over. In one-part sprint planning all three Scrum team roles are present during the entire meeting.

Daily Scrum

The daily scrum is a critical, daily inspect-and-adapt activity to help a self-organizing team better manage the flow of its work during a sprint to get the job done. The daily scrum allows the development team members to share with each other the big picture of what is happening so that they can collectively understand how much to work on, which items to start working on, and how to best organize the work among the team members in order to meet the sprint goal.

As such, all of the development team members are required to be there. The ScrumMaster should also attend, in the role of coach and facilitator. But what about the product owner? My rule for product owners is “attend when you can, but we understand that you can’t always attend.” Meaning the product owner is not required to be at the daily scrum. Or stated another way, if the product owner is not at the daily scrum, the meeting can and will still take place.

Others might also want to attend the daily scrum—managers, stakeholders, anyone, really, who wants to better understand how the team is progressing toward the sprint goal. Those individuals should be invited to come to any of the daily scrums, with the clear understanding that they are there to observe, rather than actively participate. The meeting is intended to be development team members sharing information with each other—not a status report to the ScrumMaster, product owner, or anyone else for that matter. The ScrumMaster should enforce the general rule that non-Scrum team members should be seen and not heard.

What about the product owner, is he an active participant if and when he attends a daily scrum meeting? Many people believe that if the product owner is at the daily scrum he should be in listen-only mode. When applying Scrum, being practical trumps everything! Often when a product owner attends a daily scrum he doesn’t have anything to contribute to the discussion—his value in attending is to better understanding what is occurring during a sprint. So, in this case, the product owner is probably sitting and listening.

However, what if a developer says, “Today I am planning to work on task 5; but I have to admit I am a little fuzzy on exactly what we are trying to accomplish from a business perspective.”  If I was the product owner at that daily scrum and I could clarify the fuzziness with a very brief explanation (like a sentence or two), I would certainly speak up and clarify things for the development team. That is just me adding value as the product owner. If a lengthier explanation were required, I would probably say something like, “Hey, I would be happy to stick around after the daily scrum and clarify that!”  In either case, in this example, I wouldn’t have just sat there and said nothing.

You can read more about the daily scrum in Chapter 20 of Essential Scrum.

Sprint Review

The sprint review is a meeting that gives everyone with input to the product development effort an opportunity to inspect and adapt what has been built so far. The sprint review provides a transparent look at the current state of the product, including any inconvenient truths. It is the time to ask questions, make observations or suggestions, and have discussions about how to best move forward given current realities. The goal of the sprint review is not to give a demo. See my blog post “It’s a Sprint Review Not a Sprint Demo.”

Based on the purpose of the meeting the following sources of attendees are expected:

Do All Development Team Members Need to be Present?

Yes! All development team members should be present at the sprint review to hear stakeholder feedback firsthand.

You can read more about the sprint review in Chapter 21 of Essential Scrum.

Sprint Retrospective

Whereas the sprint review is a time to inspect and adapt the product, the sprint retrospective is an opportunity to inspect and adapt the process. During the retrospective, teams are free to examine what’s happening, analyze the way they work, identify ways to improve, and make plans to implement these improvements. Anything that affects how the team creates the product is open to scrutiny and discussion, including processes, practices, communication, environment, artifacts, tools, and so on.

Because the sprint retrospective is a time to reflect on the process, we need the full Scrum team to attend. This includes all members of the development team, the ScrumMaster, and the product owner. The development team includes everyone who is designing, building, and testing the product. Collectively, these team members have a rich and diverse set of perspectives that are essential for identifying process improvements from multiple points of view.

The ScrumMaster attends, both because she is an integral part of the process and also because she is the process coach for the Scrum team and can point out where the team is not adhering to its own agreed-upon process and also be a valuable source of knowledge and ideas for the team.

Some argue that the product owner should not attend the sprint retrospective. They believe that having the product owner at the retrospective might inhibit the team from being completely honest or revealing difficult issues. While this can be a risk in some organizations, the product owner is a critical part of the Scrum process and as such should be part of discussions about that process. If there is a lack of trust between the product owner and the development team, or there is a low level of safety so that speaking candidly isn’t comfortable, perhaps the product owner should not attend until the ScrumMaster can help coach those involved toward creating a safer, more trusting environment.

Assuming trust and safety are reasonably in place, an effective product owner is critical to achieving the fast, flexible flow of business value and therefore should participate in the sprint retrospective. For example, the product owner is the channel or conduit through which requirements flow to the team. What if something is wrong with how requirements are flowing through the Scrum process? Perhaps PBIs are not well groomed by the start of sprint planning. In such cases it would be difficult for the Scrum team to brainstorm potential process improvements if the product owner were absent from the retrospective.

You can read more about the sprint retrospective in Chapter 22 of Essential Scrum.

Product Backlog Grooming (Refinement)

Product backlog grooming (sometimes called product backlog refinement) refers to a set of three principal activities: creating and refining product backlog items (PBIs), estimating PBIs, and prioritizing PBIs.

Grooming the product backlog is an ongoing collaborative effort led by the product owner and including significant participation from internal and external stakeholders as well as the ScrumMaster and development team.

Ultimately there is one grooming decision maker: the product owner. However, good product owners understand that collaborative grooming fosters an important dialogue among all participants and leverages the collective intelligence and perspectives of a diverse group of individuals, thereby revealing important information that might otherwise be missed.

Good product owners also know that by involving the diverse team members in the grooming, they ensure that everyone will have a clearer, shared understanding of the product backlog, so less time will be wasted in miscommunications and handoffs. Such collaborative efforts also go a long way toward bridging the historical gap between the business people and the technical people.

Stakeholders should allocate a sufficient amount of time to grooming based on the nature of the organization and the type of project.

As a general rule, the development team should allocate up to 10 percent of its time each sprint to assisting the product owner with grooming activities. The team will use this time to help create or review emergent product backlog items as well as progressively refine larger items into smaller items. The team will also estimate the size of product backlog items and help the product owner prioritize those items based on technical dependencies and resource constraints.

Let me summarize the participants in each of the three different product backlog grooming activities.

Grooming – Creating and Refining Product Backlog Items

The product owner is responsible for making sure PBIs are written and appropriately refined. Although the product owner might be able to do this work by himself, in my experience PBIs are much better when grooming is performed collaboratively with the development team and stakeholders, and under the coaching and facilitation of the ScrumMaster.

Also collaboratively writing and refining PBIs provides everyone involved with fast feedback that allows the Scrum team to prune bad paths quickly and discover emergent opportunities faster. For example, if I am the product owner and I write the user stories by myself and then present them to the development team, someone on the development team might say, “You know, there is a totally different way to think about this and that would require completely different user stories than the ones you wrote.” If I agree, then I (the product owner) might have just spent half a day writing stories that I now want to discard.

You can read more about the creating and refining of product backlog items in Chapter 5 of Essential Scrum.

Grooming – Estimating Product Backlog Items

If your teams choose to size the product backlog items (not all teams do), then who should be involved?

The full Scrum team participates when sizing product backlog items – and uses an estimation technique like Planning Poker. During the estimating session, the product owner presents, describes, and clarifies PBIs. The ScrumMaster coaches the team to help it better apply its estimation technique. The ScrumMaster is also constantly looking for people who, by their body language or by their silence, seem to disagree and helping them engage. And the development team is collaboratively generating consensus estimates. To be clear, only the development team members get to size the items, but the ScrumMaster and product owner are present and participating in their own ways during the activity.

You can read more about estimating product backlog items in Chapter 7 of Essential Scrum.

Grooming – Prioritizing Product Backlog Items

Ultimately the product owner is responsible for the items in the product backlog and their ordering (prioritization). However, the development team has specific technical knowledge of PBIs that could affect how the PBIs get ordered in the product backlog, so its input is necessary to prioritize the backlog. And, of course, stakeholders (e.g., business executives, customers, etc.) will have important input into how the PBIs should be prioritized to best meet their business needs. The product owner has to take input from all of these sources and synthesize it into one coherent product backlog.

Summary of Scrum Meeting Participants

Below is a tabular summary of who should attend each of the Scrum meetings.

Conclusion

Let me conclude by saying that not everyone will agree with me on who should attend Scrum meetings! And, I am okay with that. If a different approach is working well in your organization then view my opinions on who should attend Scrum meetings as one source of input in your continuous effort to inspect and adapt and make your organization more agile!