A Scrum team consists of three clear accountabilities: one Scrum Master, one Product Owner, and Developers. Often, when working with a Scrum team struggling with excessive conflict or a lack of trust, I find the culprit is a lack of clarity around each of the three accountabilities. Even with the best intentions, the Product Owner can become too focused on the upcoming Sprint and not focused enough on the bigger picture. The Scrum Master can become overly protective of the team, and the Developers - wishing only to please - can take on too much work, which can jeopardize team's ability to meet the Sprint Goal.
Indicators of a lack of clear accountability on a team might include:
The Product Owner has not communicated a Product Goal
The Product Backlog does not have enough work ‘ready’ for the upcoming Sprint
The Developers or business stakeholders demand an ROI calculation should be used for ordering the Product Backlog
The Developers do not feel comfortable determining how much work to pull into the Sprint Backlog at the Sprint Planning meeting
Stakeholders or IT managers routinely call on Developers to add work to the Sprint
The Scrum Master does not allow IT managers to attend any Scrum events
The resource manager criticizes the Scrum Master for not increasing the team’s velocity Sprint over Sprint
The business stakeholders provide direction to the Scrum team on how to organize to deliver their work
Architects or other subject matter experts are unsure of how to provide guidance to the Scrum Team
If you spot one or more of these indicators, a deeper understanding of the accountabilities on a team can improve how it functions.
A deeper dive into the Scrum accountabilities
What the Product Owner does
The Product Owner represents the interests of the business or community product stakeholders through the content and order of the Product Backlog. They may delegate this work, but remain accountable, and no one can tell the Developers to work from any other list.
How they do it
The Product Owner develops and communicates a Product Goal. Based on the Product Goal, the Product Owner creates and orders a Product Backlog (or to-do list), which contains the work needed to improve product value and makes it transparent and accessible. The Product Owner may create a forecast or roadmap to aid communication with stakeholders or customers.
Why they do this work
The Product Owner is responsible for maximizing the value of the product resulting from the work of the Developers. Without a single individual with decision-making authority determining what the Scrum team will work on next, the Scrum would lose focus on their goals and value delivery would be diminished.
Common Product Owner anti-patterns:
They haven’t identified a Product Goal
Why this happens: The Product Owner may be focused on getting enough ‘ready’ work for the upcoming Sprint or may not be aware that a single Product Goal is necessary.
Do this instead: Just like a ship without a rudder, a Scrum Team without a goal can change directions so frequently that it doesn’t achieve any value at all. When the Product Owner develops and communicates a Product Goal for the Scrum Team to aim for, each Sprint is a step towards that goal. Opportunities to share the Product Goal include at the Sprint Planning and Sprint Review events. The Product Owner can also share the Product Goal in refinement or stakeholder meetings. The Product Backlog includes the Product Goal.
The Product Backlog does not include enough work for the upcoming Sprint
Why this happens: This often happens with newer Scrum teams because the Product Owner has not had time to build up a Product Backlog of ready work.
Do this instead: While the Product Owner is accountable for the content and ordering of the Product Backlog, they may choose to delegate those tasks to Developers or others within the organization, such as business analysts, for example. Additionally, refinement meetings can be an opportunity for the Product Owner to collaborate with the Developers and stakeholders to build out a Product Backlog quickly.
What Developers do
Developers estimate, plan, and execute the work of the Scrum Team. They collaborate with the Product Owner to maximize Product Backlog value and determine what work to pull into the Sprint (Developers own the Sprint Backlog).
How they do it
Developers self-manage; no one--not even the Scrum Master--tells the Developers how to turn Product Backlog items into a useful increment at least once per Sprint. Generally, Developers are cross-functional, with all the skills as a team necessary to perform work in the Product Backlog. Developers use the Sprint Backlog to plan work and the Daily Scrum as a checkpoint for measuring Sprint Goal progress. There are no hierarchies among Developers on a Scrum Team; everyone is accountable together for delivering a useful increment at least once per Sprint.
Why they do this work
To deliver a done, usable increment at least once per Sprint.
Common Developers anti-pattern:
Developers, Resource Managers or Stakeholders may demand using a specific ROI calculation to order the Product Backlog
Why this happens: This can be a sign of a lack of confidence in the Product Owners’ decision-making.
Do this instead: The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum team. One of the Product Owner’s tools is the Product Backlog. The Product Owner can order the items in the Product Backlog any way they deem best. For example, they may decide that some quick wins would help build trust with the customer base, or they may decide to order items purely based on ROI. Although the Product Owner has full discretion about how to order the list, they should gain input from stakeholders (including the Developers). Doing so will help the Product Owner to make the most informed decisions about ordering the Product Backlog.
Stakeholders or IT managers routinely call Developers to ask them to add work to the Sprint
Why this happens: Stakeholders or IT Managers may be unaware of the Product Owner accountability.
Do this instead: Developers should direct stakeholders to the Product Owner regarding additional work and/or the Scrum Master should provide coaching to the impacted Stakeholders or IT Managers. Only the Product Owner can decide how to order the Product Backlog.
What the Scrum Master does
The Scrum Master is accountable for establishing Scrum as it is described in the Scrum Guide. It sounds simple, but it isn’t. Being a Scrum Master involves more art than science. The perfect Scrum Team does not evolve overnight. It can take years to become a high-performing unit. A wise Scrum Master knows what challenges to tackle first.
Why they do this work
The Scrum Master is a servant leader of the team whose purpose is to increase the effectiveness of the Scrum Team by improving its practices.
Common anti-patterns:
The Scrum Master does not allow resource managers to attend Scrum events
Why this happens: In some organizations, members of the Scrum Team may report to IT or other resource managers. These managers may not understand their role and how they should relate to the Scrum Team.
Do this instead: The Scrum Master can coach managers in how best to interact with the Scrum Team. For example, managers attending the Daily Scrum should avoid interfering with this daily opportunity for Developers to synchronize. The manager’s sole role should be to identify and remove impediments or to promote a culture of trust among Scrum Team members.
The resource manager criticizes the Scrum Master for not increasing the team’s velocity Sprint over Sprint
Why this happens: The resource manager may be looking for ways to support the Scrum team but is unaware of the right way to interact with the Scrum Team.
Do this instead: Velocity is a tool internal to the Scrum Team that it uses to plan and organize its work. Velocity is not a ruler for measuring team success. Use value metrics instead, which measures the product’s value. The resource manager should be encouraged to participate in the Professional Agile Leadership Essentials class offered by Scrum.org for more information about how to support and coach Agile teams.
The business stakeholders provide direction to the Scrum Team about how to organize to deliver their work
Why this happens: The business has a vested interest in the success of the Agile team but is unclear about how best to engage with a Scrum team.
Do this instead: No one, not even the Scrum Master, tells the Development team how to turn Product Backlog items into a ‘done’ Increment. Encourage the Scrum Team to self-manage to deliver the work. By empowering teams to own the delivery of their own work, organizations can unleash greater creativity and problem solving skills from all Scrum team members.
The table below provides an overview of each of the accountabilities included in the Scrum Team:
Sign up for Rebel Scrum’s Professional Agile Leadership course to learn more about how leaders support agile teams of all kinds - not just Scrum teams! If you are a Scrum Master, signup for Rebel Scrum’s upcoming Professional Scrum Master course. Advanced Scrum Masters should signup for Rebel Scrum’s Professional Scrum Master II course.
Join us for a day of learning and discussion at next year’s Scrum Day Madison, scheduled for September 14, 2023, in Madison, Wisconsin at the Alliant Energy Center.
