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 these 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, jeopardizing the Sprint Goal.
Indicators of a lack of clear accountability on a team might include:
- The Product Owner has not developed or communicated a Product Goal
- The Product Backlog does not have enough work ‘ready’ for the upcoming Sprint
- The Development team or business stakeholders demand an ROI calculation 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:
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.