New Scrum RACI for Roles & Responsibilities | Jesse Fewell New Scrum RACI for Roles & Responsibilities – Jesse Fewell

New Scrum RACI for Roles & Responsibilities

By July 1, 2014Blog, Uncategorized
Scrum RACI for Roles and Responsibilities


Scrum is by far and away the most popular of all the agile methods in use today. A key feature of Scrum is the distribution of responsibilities across three roles: a business representative (Product Owner), a group of skilled professionals building a product (Development Team), and a facilitator who removes obstacles (ScrumMaster). These roles have become ubiquitous in Agile projects across the world.

Several people have tried to answer this question with a good old fashioned RACI chart (responsible, accountable, consulted, informed). Whether a  this downloadable PDF, or detailed treatise, or even an article published by the Scrum Alliance itself. Unfortunately, each of these “Scrum RACI” examples to try to do too much, offering up way too much detail that leaves many of my clients wondering about how it works on their project instead. I think the RACI format itself is to fault. What if we answered a more basic question instead? More to the point,

“What does the textbook say about who-owns-what, regardless of what kind of project I work on?

Instead, I’m going to use a different approach, by emphasizing who owns a given responsibility versus who helps that owner. I find “Owns-Helps” is much easier to articulate than the conventional RACI format. First, I’ll share the infographic you can download, followed by a description.

The Product Backlog, and its related Refinement, are absolutely owned by the Product Owner. She decides which workshops, meetings, plannings, or updates need to happen to create and update the backlog. However, a good Product Owner will ask for help from the Development on dependencies, estimates, tradeoffs, and event test criteria. She will also ask the ScrumMaster to help resolve any issues. A ScrumMaster can help facilitate alignment across stakeholders. The Product Owner can even ask for help organizing the backlog in a way that is understandable by various parties.

The Sprint Planning and its resulting Sprint Backlog are jointly owned by the Product Owner and the Development Team. The Product Owner decides what is most important to work on right now, in the upcoming Sprint. Meanwhile, the Development Team decides how much of the Product Owner’s priorities are feasible in the Sprint’s timeframe. If they’re good their job, they’ll ask the ScrumMaster to facilitate some good dialog about this difference of perspective. Granted, the Development Team can spend some time in the meeting to craft a tactical plan for how the backlog items will get built. That may help them gain confidence as to what’s feasible for the Sprint. But whatever goal, whatever agreement, whatever forecast comes out of Sprint Planning is jointly owned by the Product Owner and the Development Team.

The Daily Scrum and the Product Increment are absolutely owned by the Development Team. Nobody touches the Product Increment during the Sprint, except the Development Team. Also, they use the Daily Scrum meeting as a tool to help them coordinate the steps and actions needed to build the Product Increment. If they are wise, they will ask the Product Owner for help to clarify business details, or even to shield them from other stakeholders. Furthermore, they can ask the ScrumMaster for help facilitating the Daily Scrum and removing impediments. The newer the team, at the more help they will need. A common rule is that “anyone can come to the Daily Scrum, but only the Scrum Team is allowed to talk at the meeting”. This is to emphasize that the ceremony is owned by the Development Team, for their own internal benefit.

The Sprint Review is owned by the Product Owner. This is where the Product Owner gets to see what she invested the last few weeks of budget to get. She decides whether the product is in good enough shape to invite stakeholders. She decides how best to capture feedback during the meeting, and have it incorporated into the backlog. If she’s smart, she’ll ask the Development Team for help to demo the product and , since they just worked on it. She can also ask the ScrumMaster for help in establishing an effective meeting.

The Sprint Retrospective is jointly owned by all three roles. The Product Owner’s neck is on the line for how well the Sprint went; she will have strong opinions about improving. The Development Team is expected to take ownership over their work; they will have ideas about how to make that happen. The ScrumMaster is held accountable for whether the whole team is effective and reliable; he will have strong opinions about moving in that direction.

This “Owns-Helps” chart shows us that Scrum itself is a very simple framework. Granted, the devils is in the details. But Scrum leaves you to answer the question of HOW those details are attacked in your specific context. There is an the ebb and flow of responsibilities across the three roles of a Scrum Team. This yin and yang fluctuates during the course of the Sprint. It fosters more collective ownership, and allows for each of the roles to have greater focus on their specific areas.