Arrow left
Blog Homepage

Introduction to Scrum Roles and Responsibilities

Introduction to Scrum Roles and Responsibilities

For teams looking to adopt scrum, or variations of scrum ways of working, this article covers common scrum roles and responsibilities you'll encounter as you explore this way of working. There's no one-size-fits-all approach to organizing as a team, so we encourage teams to borrow what's useful and adapt it to your unique team, goals, and business needs.

The three scrum roles are as follows:

  • Product owner
  • Development team
  • Scrum master

The product owner

A product owner is empowered, and responsible for, maximizing the value of what gets shipped and ensuring the delivered product meets customer needs. They ensure the development team is working on the most impactful pieces of work that move the business, the product, and team goals forward. The product owner acts like traffic control, organizing what is built and when, clearly communicating why.

In practice, amongst their many roles as a key stakeholder in product, they manage a product backlog. This includes prioritizing which Issues should be worked on first, why, and ensuring each item is clearly described and communicated to the team.

This includes keeping all stakeholders (like customer-facing teams or executives) aligned with priorities and what’s being delivered. A product owner is the go-to for questions that arise and will continue to clarify issues. They also help the team prioritize against any disruptions or urgent matters that come up within a Sprint.

Managing the movement of Issues in your workflow in ZenHub Boards

Any new Issue created, whether it’s a feature request, tech debt, bug report, or internal piece of work, automatically land in the far left pipeline on your team’s Board (consider this your triage, inbox, or to be reviewed pipeline). Here at ZenHub, our product owners scan each Issue to review the ask and impact to quickly decide whether it’s high priority, needs to be immediately actioned, or should be further flushed out.

Issues then get moved accordingly into further pipelines, such as a Backlog, Icebox, or Defining Goals, with highest priority Issues at the top of each pipeline. We think of this process as grooming the Board, and keeping information updated. The goal is to keep your far left pipeline empty (similar to inbox zero!)

Here at ZenHub, our product owner also uses an Icebox pipeline to “freeze” stories that aren’t a priority. Keep in mind that while the product owner is empowered to have accountability over the backlog, we always encourage team accountability. Everyone in the team should be able to nominate work, start dialogue about priority, or raise important Issues that need to be addressed.

The Icebox represents items that are a low priority in the product backlog. We don't want to delete these and create a cycle of raising duplicate Issues, so we keep them in our icebox with just enough information attached that we can pick it up some time in the future -- if and when we choose to do so.

A product owner can also help facilitate a retro after each Sprint to discuss what went well, areas that were over or under-estimated, opportunities for improvement, and to help guide conversations around what needs to change in the upcoming Sprint.

The development team (or squad)

The development team crafts and grows your product! They make business goals and visions become a reality, building the features and functions that the product owner prioritizes.

Teams or squads continuously work towards delivering releasable code. Typically, we see teams work within Sprint cycles, or, in cycles short enough to work on small units of work where they can deliver value each iteration. This encourages a continuously cycle where the team gets to see the impact they're making within short bursts of time.

Each team should have the autonomy to self-organize. They make decisions based on what works best for them and the work that’s been prioritized—how the team is structured, who works on what, and which Issues they commit to each sprint.

We encourage teams to adopt a non-strict hierarchy approach to self-organization. Instead, everyone is working towards the same goal. This means being cross-functional, with an eye towards continuous knowledge sharing and levelling up each other's skills.

We encourage teams of up to 7-9 people, and tend to air on the side of small pods rather than large ones. This ensures teams are focused, and can stay relatively process-light, working in a way most effective for the personalities and cross-functional nature of each squad.

More on sprints and organizing work for teams on the Board

At the start of the Sprint, we encourage teams to discuss the highest priority Issues from the Product Backlog and move them into a Sprint Backlog.

When moving Issues, the team should ensure there are proper estimates, a clear understanding of an Issue and what needs to be delivered (you might know this as 'acceptance criteria'), spurring conversation and ‘rejecting’ work that is incomplete, ill-defined, or otherwise not properly scoped to be worked on.

After the Sprint starts, work freely flows from the Sprint Backlog (or equivalent) throughout your version of In progress, code review, and ready to be released. We encourage individuals to assign the work they’re working on as it gets picked up, leverage Issue dependencies for any blockers that come up, and roll larger themes of work up to an Epic for easier filtering and tracking.

A note on team knowledge sharing

While members often have areas of expertise, we encourage teams to take time as often as possible to share skills and dedicate part of the Sprint to cross-functional knowledge sharing. This encourages levelling up the whole team, allowing anyone to take on any Issue in the Backlog as you continue to iterate.

For example, although a developer may specialize in testing, they may take on an infrastructure task if it’s at the top of the Sprint Backlog, and other developers with expertise in that area become co-assigned to answer questions as necessary.

You may also want to have a planning day to share knowledge, uncover risk, and discuss gaps within the team. We believe teams should be working together, moving away from individual performance or concepts of "my part". Instead, they should focus on how everyone is contributing to the same goal, or end state.

A very important note is that no two teams are the same! When adopting new ways of working, or iterating on your process, being too prescriptive, or worrying about following 'rules' means you might be missing the nuances of how your team actually works together. A team that jives together ships great work together :).

The scrum master

A Scrum Master supports everyone (on the team and outside the team) understand, learn, and apply scrum and agile, helping the team navigate and grow together.

There’s no concept of authority or management associated with a scrum master—they’re neither a lead nor manager—but rather a coach and teacher. A scrum master helps the product owner, the team, and the organization be successful. Whether that’s guiding a kaizen moment, helping the team resolve conflict, or protecting against mid-sprint interruptions, a Scrum Master is a guide.

Typical day-to-day things a Scrum Master may do include:

  • Ensuring that Project goals, Issue scope, and product domains are understood by everyone on the team or squad as well as possible.
  • Remove blockers to team progress and pro-actively help the team navigate how to make improvements to avoid similar blockers in the future.
  • Help the team adopt stronger development practices.
  • Lead and coach the organization in its adoption of agile or Scrum.
Product Management
Newsletter Icon