What is a productive, efficient Scrum team?

Question

How does a Scrum Master, a Product Owner know whether a Scrum Team gives much or little usefulness to a customer?

In other words, what is a productive, efficient Scrum team?

Answer 1

Build feedback loops and measures of success. Part of the problem that Scrum addresses is that in many teams, work is assumed to be valuable by the simple fact that it is given to the team. Scrum challenges that with the role of the PO. The PO, with the help of the rest of the Scrum team, should be able to measure, even in soft metrics, the value created by the team.

Now, there is a harder question of if they produce enough value. that is far more subjective. Part of the problem with most organizations is they have never measured value from a team before, so they have no baseline to compare to. If this is the case for you, you may need to take the time to baseline the value your teams create before you can make any judgement.

Answer 2

The best measure of value is going to be from feedback.

This could be direct feedback. For example, key stakeholders should be present at the Sprint Review and these stakeholders can provide feedback on the product, how it's being used, and the current state of the Product Backlog with respect to needs and expectations.

Indirect feedback, such as measuring and monitoring the sales and use of the product can also provide feedback. The specifics of this depend on what your product is and how it's marketed and sold.

Some process measurements may also be of use. Cycle time for units of work and time from idea to delivery can provide insight into the organization's ability to respond to a demand for change.

However, I'd point out that the Scrum Master isn't necessarily the one who would be interested in this data. The Product Owner would be the one who is interested in maximizing the value delivered by the team, but the Scrum Master may work with the team and the stakeholders to figure out how to get the information and make it transparent.

Answer 3

The principles of transparency, inspection and adaptation are at the hearth of the empirical process control optimizing the value of the Scrum Team's work. scrum.org

Scrum should deliver value to the customer on every sprint; the scrum master should be measuring that value and verifying/validating the value with the customer.

This isn't an issue peculiar to scrum, this is customer experience management. The obligation to coordinate with your customer and manage expectations about value, quality, cost and investment is above whatever project management methodology you adopt.

How does a PO judge value? Loosely stated, the purpose of the PO role is to communicate/coordinate value. Asking how a PO measures value is like asking how water obtains "wetness".

Answer 4

TL;DR

Your fundamental question seems like it's rooted in Theory X management, where individuals or teams don't perform unless "held accountable" by authority figures. This is not how Scrum (or agile systems in general) work. Per the 2020 Scrum Guide:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how....The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

If you measure the business outcomes of a project, the potential market value of a Product Goal, and evaluate the predictability of the Scrum Team's delivery cadence (pragmatically, meeting its Sprint Goals more often than not) then you are much more likely to be measuring something that matters to the business. Proxy metrics like "productivity" or "efficiency" mostly measure throughput, not value, and therefore measure the wrong things for most of the domains where Scrum is a good fit.

Analysis

First of all, the Scrum Master and Product Owners are members of the Scrum Team. They are not outsiders, managers, or otherwise empowered to sit in judgement of the team's "productivity." An effective Scrum Team is self-managing, so staffing a team with people who can't or won't measure their own efficacy in meeting Sprint Goals, Product Goals, or the Definition of Done won't magically be made more effective by adopting Scrum.

Secondly, articles like this one point out the futility of trying to measure team or individual productivity. Productivity in the traditional business sense (I shan't argue dictionary definitions) is generally a proxy metric that measures units of output rather than value, and is therefore rarely useful in evaluating knowledge work.

Is a Scrum Team that delivers 5,312 PBIs to achieve the first key Product Goal more efficient or effective than one that takes 143 PBIs to deliver an unrelated Product Goal? It's like asking which weighs more: a pound of feathers or a pound of rocks. Both weigh the same, but it's a good bet that the volume differs. Does the business care about weight, volume, or something else? No one outside your organization can answer that for you.

Solution

What you should do instead of using proxy metrics is to directly measure business outcomes. An effective, self-managing Scrum Team routinely delivers Increments of the Product Goal. How the company or the Product Owner measures value is likely to be product- or market-specific, but it is arguably the Product Owner's core responsibility. The 2020 Scrum Guide says (emphasis mine):

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Pragmatically, it is really senior management that determines whether the product is valuable, and whether individual Increments on the way to the Product Goal are inherently valuable or simply stepping stones to delivering value. In either case, the business and stakeholders operate through the Product Owner to create that value, and review the potential value of each Increment during the Sprint Review.

As an empirical control framework with a highly predictable delivery cadence, you can evaluate the value delivered by the project at routine intervals (e.g. at the end of each Sprint). Since each Increment ideally represents a potentially-shippable increment of value, the project sponsors, stakeholders, customers, or marketplace should provide you rapid and regular feedback about whether the project is delivering the value and business outcomes that are required for success. The project sponsors can then use that feedback to determine whether the project remains a good investment.

If at any point the project is projected to cost more than it's worth to the business, the Scrum framework allows the Scrum Team to adapt its goals and processes (if it's useful to do so). Likewise, the business always has the option to terminate the project rather than continuing to chase a sunk cost. Scrum doesn't guarantee that a given project will succeed. It just makes the trajectory of the project visible and transparent to everyone involved, enabling the Scrum Team to inspect-and-adapt and the business to "fail fast" when necessary.

Conclusion

To sum up, accurate metrics come from measuring empirical business outcomes, not evaluating the Scrum Team or its members through proxy metrics. The Scrum Team is expected to contain cross-functional, self-managing people who hold themselves accountable for delivering value. The business and the marketplace decide what is valuable, but you need to trust and empower the Scrum Team to deliver that value.

If trust is a foundational issue, or your "team" is really just a loose collection of mediocre individuals, any real-world solution must address those process problems first. Without the proper foundation, neither Scrum nor Theory X management can save a doomed project, no matter how much blame gets spooned around.

Answer 5

Scrum has two build in feedback cycles dedicated to "productivity" and "efficiency".

Citing the Scrum Guide: "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master."

I would like to point out, that the PO and SM are part of the Scrum Team just like the developers. They are not outsiders looking into the team, they are part of the team and therefore have knowledge of everything going on within the team.

Optimizing the productivity of the team is the main responsibility of the PO. The PO makes sure there is a product vision and that each sprint makes valuable progress towards that vision. At the end of each sprint the Product Increment is discussed with stakesholders. These stakeholders will be able to give feedback whether sufficient value is provided to warrant continued product development.

The Scrum Master helps the team become better at Scrum. That includes becoming more efficient. The Retrospective is an event at the end of each Sprint that is focused on exactly that: Discussing the way the team works together and improving continuously. The Scrum Master helps keep the team accountable and helps make improvements more visible. All team members should be able to judge how efficient the working process is. ("We're talking all day and getting nothing done. We struggle to make decisions and flip-flop a lot. We're getting in each other's way all the time." vs "Our discussions are on point and we make fast decisions. We work together as a team effortlessly.")