Scrum Roles and Responsibilities Explained

Scrum is a powerful framework that helps teams deliver value to customers quickly and frequently. But without understanding the roles and responsibilities on a Scrum team, the process can fall apart quickly and frequently, too.

Failed Scrum transformations sometimes emerge from a lack of clear understanding about these different roles and responsibilities – or as the Scrum Guide now calls them: accountabilities. Failure to set your team up the right way can lead to all sorts of problems: product delays, features customers don’t need, unhappy teams, and, worst of all, organizations abandoning Scrum unnecessarily.

We’ll help you avoid these and other challenges by explaining the roles you need on a Scrum team and what they are responsible for.

Scrum teams work in cycles (called Sprints) that follow a consistent rhythm of planning, execution, and reflection to facilitate continuous improvement of the work process.

Scrum teams are cross-functional, so they have all the skills to accomplish their work. They’re also self-managed. The team – not an outside manager – decides what gets worked on next, who works on it, when, and how. There are no sub-teams or hierarchies on a Scrum team.

It’s tempting to talk about Scrum “roles and responsibilities” – we’ve done so in the title of this blog – but the latest edition of the Scrum Guide refers to Scrum team roles and responsibilities as “accountabilities”. 

There are three core accountabilities on a Scrum Team:

It’s that simple. But to perform well in one of these roles, you’ll need a deeper understanding of the detailed responsibilities of each role and the potential pitfalls you may come across.

A Scrum team’s developers create a plan for achieving the Sprint goal. In Scrum, each Sprint has a specific objective the team sets together with the Product Owner during Sprint Planning. Say, for example, your Sprint’s goal is to “increase DAU (Daily Active Users) by 2% through improving the onboarding funnel.” It’s then up to the team to determine how they want to achieve this objective and add relevant tasks to the Sprint Backlog – the list of work for that Sprint.

The developers review progress towards the Sprint Goal every day during the Daily Scrum meeting. If necessary, they adapt their plans and tasks to ensure they can still hit the objective in case of problems. Usually, this means dropping low priority or nice-to-have functionalities from the Sprint Backlog.

If you assess with the Scrum Master that there’s no way to fulfil the Sprint Goal, then you’ve probably taken too much on. Using an agile estimation process like Sprint Poker might help you apportion the right amount of work. If you planned your work and still didn’t reach the Sprint Goal you can then determine the reasons during the Sprint’s Retrospective meeting, to extract learnings for future Sprints.

Here are some common challenges developers might face when working as part of a Scrum team with a Product Owner and a Scrum Master. 

Development teams might struggle to switch from individual to team accountability. In Scrum, an individual is never solely responsible for the outcome of a Sprint – whether that’s a good or bad result. Team accountability puts the responsibility for giving credit and resolving issues on the team as a whole, not an outside manager or individual contributor.

Lack of trust between the development team and their Product Owner can also be an issue. There can be valid reasons Scrum teams come to distrust Product Owners – for example, if the PO dictates how the work should be done or gives hard deadlines.

But some development teams reject Product Owners too soon. They lack an understanding of the complexity of the PO role and label them as clueless business folks without giving the PO a chance to prove their value. Or they distrust the PO simply for not having as much technical expertise as some team members.

A skilled Scrum Master can help build understanding between the two parties in such a situation by acting as a mediator and coaching them on their relationship. They can also come together in a Retrospective meeting hosted by the Scrum Master to uncover issues and mend their relationship.

Product Owners develop and maintain the vision for the product – what problems it solves and for whom. And they make decisions about what should be built next.

The Product Owner also represents the voice of the customer and the business during the Scrum process. They spend a lot of time with both parties to understand their needs.

They need to know why specific features bring value to the customer or the organization and communicate that value to the team. Such a vision helps inform product prioritization decisions and should motivate teams to understand the purpose of their work.

At the same time, the Product Owner needs to work closely with the development team. The Product Owner is responsible for constantly updating and prioritizing the Product Backlog so that stakeholders have visibility into what the team is working on – now and in the near future – by referring to the Backlog. Keeping the Backlog up to date is also crucial to ensure items are sufficiently detailed and up to date for each Sprint Planning meeting.

Product Owners are responsible for ensuring the company builds the right product. The developer team are responsible for making sure the product is built right.

Here are some challenges you might face as a Product Owner in an ambitious company. Particularly if you’ve come from a regular project management background and transitioned into a Product Owner role. 

Product Owners that come from a traditional project management background may have to unlearn a lot of the best practices of previous roles. Product Owners in Scrum can only indicate what work the team needs to do – not how to do it or how much the team should complete each Sprint. A traditional project manager may find it more natural to make long-term work-plans and assign tasks to individual team members. But that’s not how Scrum works. Part of being a great Product Owner is knowing where to step in and where to step back.

Balancing the time Product Owners spend with the development team versus customers and other stakeholders is another challenge. Preference for one group leads to a disconnect with the other, neither of which is beneficial to creating a great product.

This imbalance might stem from a Product Owner’s background. They might be uncomfortable with the role’s business and customer side if their background is technical. If their background lies somewhere else – like marketing – they might struggle to gain the trust of the developers on a Scrum team.

In some organizations, Product Owners don’t really get what their name implies – ownership over the product. Juggling a product vision, the responsibility for the Backlog, and liaising between all parties is already tricky enough. Product Owners may often feel they are stuck in the middle managing business needs on one side and developer needs on the other. The best Product Owners listen but have convictions and the confidence to push forward with their vision and bring people on board with it, rather than trying to please everyone all the time.

A Scrum Master helps the team as a whole practice Scrum by guiding them on how to work together more effectively and continuously improve their work processes. Each Scrum team includes one Scrum Master.

Beyond implementing solid processes, the Scrum Master protects the team by helping to resolve issues and remove impediments outside of their control. This protection can, for example, involve addressing a Product Owner who oversteps boundaries by telling the team how to do their work. It can also include creating understanding about Scrum and Agile with higher-level managers or other departments.

Scrum Masters also train and coach the broader organization in its Scrum adoption to help teams become self-managed. The Scrum Master is the expert on Scrum and acts as a coach that teaches, facilitates, and protects the Scrum process. Sometimes a freelance Agile coach might also take on the Scrum Master role. They’ll then slowly transfer skills, knowledge, and responsibilities to people within the organization until the team no longer needs them and is functioning as a high-performing self-managed team.

Here are some challenges you might face working as a Scrum Master or with one.

Scrum Masters face similar challenges to Product Owners. They don’t wield authority over the day-to-day work of the team members but empower them to take responsibility for it themselves. They can’t control the work, but they are responsible for improving the work process. So a Scrum Master can change the structure of a meeting but not force someone to be present. That limitation becomes even more challenging when managers send in a Scrum Master to deal with a “problematic” team that’s fine with the way they’re currently working. A Scrum Master’s only fallback in such a situation – and many other ones – is to have great people skills, as they deal with various personalities and interests across an organization.

Despite the purported constraints on the Scrum Master’s role, some do end up playing God. Some Scrum Masters don’t sufficiently empower the team through training and coaching to take over the Scrum process. Instead, they make the process dependent on themselves, usually by taking – and keeping – control of meeting facilitation and other team rituals.

Alongside building a team’s reliance on a Scrum Master, another bad habit is upholding Scrum’s rules at all costs. Scrum Masters exist to help teams master Scrum. But helping teams thrive doesn’t always mean following the rules to a T. Instead, great Scrum Masters help teams evolve their processes based on what’s best for the team, even if that means adopting a different Agile framework.

Scrum teams come together multiple times per sprint to run different Scrum ceremonies or meetings. So far we’ve covered the broad roles and responsibilities of each Scrum team member. But not who is responsible for what when teams come together. 

Retrospective meetings are the odd one out in this case. Everyone owns the retrospective meeting. This might mean that you rotate the facilitator role each Sprint, for example. But on a deeper level, it means that all team members are responsible for improving working processes and helping the team evolve.

According to research from Harvard Business Review, “collaboration improves when the roles of individual team members are clearly defined and well understood.” Scrum helps achieve such clarity through its definition of the three roles on a Scrum team.

That’s not to say you can’t make any adjustments. The essence of Scrum is to experiment, learn, evolve, and continuously improve how you work. You can adjust or add roles if there’s a valid reason for doing so, but make sure you’ve mastered the three formal Scrum roles and their responsibilities first.