Building Your First Scrum Team – Introduction to Scrum Roles and Responsibilities

Working with Scrum for the first time? Many small companies start doing this chaotically, not knowing exactly what’s required for this framework to work the way it should.

In particular, using Scrum as per guidelines requires getting three new roles on board: Product Owner, Development Team, and Scrum Master. You might be thinking: “I already have a great development team.” But how accustomed are they to Agile or Scrum best practices?

Yes, that’s one role you’ve already got covered. Partially. Here’s where the Scrum Master comes in to ensure your team members become experts at working within a Scrum workflow.

But the Scrum Master supervises Scrum and Agile processes and doesn’t get into the nitty-gritty of tasks. With complex projects, you’ll also need a Product Owner to manage the backlog and prioritize every person’s duties.

To help you get a better understanding of what each role does, we’re covering all of the in-demand Scrum roles and responsibilities you’ll encounter as you explore this way of working with your team.

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 team roles are as follows:

• Product owner
• Scrum Master
• Development team

I’ve analyzed over 200 job descriptions for each one of these Scrum roles to see what common responsibilities they require. Let’s go through them!

The Product Owner

A product owner is 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 organizes what is built and what the timeline looks like, clearly communicating why.

In practice, amongst their many roles as a key stakeholder in the 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.

Product Owner responsibilities

Here’s the list of potential activities and duties a product owner will have:

• Create and maintain the product roadmap, plan sprints, and create action items along with the product manager.
• Define a product’s strategic vision and align new products to it.
• Collaborate with business owners to ensure that new products or updates meet requirements and priorities.
• Manage the discovery phase for new and existing products and services
• Write epics, actionable user stories, and the acceptance criteria to help the team give accurate estimates.
• Plan and organize the deliverables of the Agile processes.
• Own the product throughout its complete delivery lifecycle.
• Collaborate and coordinate releases with other departments like marketing, development, or sales.
• Measure and find new opportunities to improve workflows with every iteration.
• Write the functional specifications on new features, bug fixes, or upgrades and turn them into tickets.
• Talk to customers to research their needs, behavior, and future opportunities.
• Analyze how users interact with the product.
• Write detailed stories and acceptance criteria based on product scope documents and epics in order for the engineering teams to develop software.
• Maintain and prioritize/reprioritize the product backlog through planning, grooming, and stakeholder review.
• Protect the scope of work in a sprint against incoming requests.
• Motivate the team through the whole product development process.
• Get stakeholder input and do market research to gather competitive information.
• Review working software with your team and internal/external stakeholders to make sure that each product change is understood, shared, and supported.
• Execute high-level product testing along with the QA team to guarantee the definition of done was achieved.

Managing the movement of issues in your workflow

For any Product Owner, the Scrum board is their home: the place where all work is analyzed, prioritized, and reprioritized when needed. Scrum boards (also known as Kanban boards) help Product Owners visualize a team’s workload and decide what each person should work on next.

Any new issue created, whether it’s a feature request, tech debt, bug report, or an internal piece of work, automatically lands in the far left pipeline on your team’s Board (consider this your triage, inbox, or to be reviewed pipeline).

At ZenHub, our product owners scan each issue to review the task 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 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 a 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 at a point 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 Scrum Master

A Scrum Master supports everyone (on the team and outside the team) to understand, learn, and apply Scrum and Agile practices, 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.

Scrum Master job description roles

Let’s see what in-demand Scrum Master roles and responsibilities they have:

• Ensure 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 proactively help the team navigate how to make improvements to avoid similar blockers in the future.
• Implement Agile and Scrum best practices throughout all teams.
• Help coordinate product specifications, sprints, meetings, sprint demos, and stand-ups.
• Track project progress and resolve potential issues the team could be dealing with.
• Offer coaching and mentoring of Agile and Scrum values and best practices.
• Use reliable sources to estimate how many deliverables are needed for each iteration.
• Help employees write effective user stories and turn them into subtasks.
• Organize code reviews and team audits to maintain quality and productivity while anticipating potential risks.
• Coordinate processes and the product’s release together with other departments.
• Help the product owner prepare the product backlog for upcoming sprints.
• Actively monitor and fix impediments to make sure the product and its features are delivered within scope, time, budget, and expected quality guidelines.
• Document all progress and communicate it to the upper management and stakeholders.

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 continuous 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 leveling up each other’s skills.

Teams should include 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.

Software development roles in Scrum and their responsibilities

Software development team members don’t usually have an authoritative role when it comes to guiding the Agile and Scrum processes. However, you’ll notice most job descriptions have a mention of what Scrum skills are needed either to accommodate new processes from the start or even replace a team lead within small companies:

• Experience working within Agile environments like Scrum and Kanban.
• Good understanding of technology development best practices (e.g. Agile) and product management methodologies.
• Confident in using Git and GitLab/GitHub and working using Kanban boards.
• Actively participate in product discussions to spot feasibility and adherence to overall roadmaps and strategies.
• Work along the product management and design teams to develop new products and features.
• Collaborate on user story analysis and elaboration.

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 Scrum teams to take time as often as possible to share skills and dedicate part of the Sprint to cross-functional knowledge sharing. This encourages leveling 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 Scrum team members 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.

Takeaways on starting a focused Scrum team

A very important point to remember 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 through all Scrum roles.

These job descriptions offer you an accurate highlight of what the current job and tech demands are. Going through these before writing down the specs for the roles within your own company ensures you won’t be asking for too little or too much from your next hire. This also means that tasks such as the Product Owner’s duty to motivate the team won’t be left unnoticed and you won’t hire someone who’s not a people-first manager for this role.

Working with a tool like ZenHub can be an option for teams that might not yet have a dedicated Scrum facilitator. In fact, organizing work in ZenHub also provides a great starting point for your future Scrum team leaders, providing the product backlog and tools needed to prioritize story points.

Getting these three roles correctly represents the foundation of a focused Scrum team where every person has their duties clearly marked and you won’t have managers clashing in their responsibilities. Have a look at our guide to building focus-driven development teams to get the next steps right and avoid any workflow gaps.