According to the Scrum Guide, Scrum teams are typically 10 or fewer, with a preference to the smaller size. When Scrum teams become too large, they should consider re-organizing into multiple Scrum teams supporting a single product. When this happens, the Scrum teams should share a single Product goal, Product Backlog, Product Owner and a common Definition of Done.
The definition of a product
We use Scrum to deliver products in complex environments. But what exactly is a product? According to the 2020 Scrum Guide, “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined end users or customers. A product could be a service, a physical product, or something more abstract.”
What the Scrum Guide means is that the definition of a Product is based on the value that it provides. Note that the definition is not based on the technology we use to deliver that value.
Multiple Scrum Teams; single product
Let’s look at an example. Imagine a company whose primary business is its subscription-based Whizbang Financial Planning website which generates more than $1 billion annually. Creating and maintaining the website requires java developers, graphic designers, content writers and testers.
In this example, the product is the website. The product is not the Java developers, content writers, or website testers. Instead, all of these individuals work together to support the Whizbang Financial Planning website – a single product.
But what if there are 20 Java developers, testers, graphic designers and content writers? Does this mean they all have to operate on the same Scrum Team? That sounds unmanageable.
The answer is no. Multiple Scrum Teams can work together to support a single product. Each Scrum Team should be cross-functional and have all the skills needed to deliver an Increment of value each Sprint.
Let’s suppose the organization creates four Scrum Teams to support the Whizbang Financial Planning website. It’s this scenario that often leads organizations to think that each team should have a Product Owner.
The whizbang Financial Planning website may have multiple teams, but it is a single product. Having one Product Owner per Scrum Team could lead to issues such as disagreement on the strategy for the website. One Product Owner might want to create a goal to increase sales, and another on cost savings. Now we lack focus and a unified goal. The Product Owner must be the single voice of the customer, and there must be a single voice per product.
The Product Owner accountability
The Product Owner is the bridge between company strategy and the Scrum Team. Senior management owns the overall company vision and business strategy (unless the entire company supports a single product, in which case the Product Owner may be the CEO). At a minimum, the Product Owner must own the product vision, goal, Product Backlog and forecasting. We can’t have more than one product goal at a time, so we only need one Product Owner.
(To learn more about the Product Owner accountability, signup for one of Rebel Scrum’s upcoming Professional Scrum Product Owner or Professional Scrum Product Owner - Advanced courses.)
That’s a lot of work!
The Product Owner is responsible for maximizing the product’s value resulting from the Scrum Team’s work. They are accountable for generating and ordering the Product Backlog, forecasting, and creating the product vision. They have stakeholder management responsibilities as well.
Yes, that is indeed a lot of work.
How does the Product Owner handle it all? The answer is delegation. While the Product Owner remains accountable for the content and ordering of the Product Backlog, they may delegate these tasks to the Scrum Team.
What about the Definition of Done?
A single product has one Definition of Done across multiple teams. Why? Because they must work together to deliver a usable Increment at least once per Sprint. Suppose one team has an understanding of what they mean when they say a particular Product Backlog item is Done, but another team has a different understanding. How will we ever have consistent quality and expectations?
If Team A conducts performance testing for every Product Backlog item it delivers, but Team B does not, our entire product has lower quality, and each team is doing a different amount of work. Having a shared Definition of Done among all teams avoids these problems. Furthermore, if a Definition of Done has been created by the parent organization, then all product teams in that organization must adopt it as a minimum.
(Are you struggling with creating a Done increment each Sprint? Check out Rebel Scrum’s post Three Steps to Done in Scrum.
What about the Scrum Master?
There is no requirement to have a single Scrum Master per product. Depending on your organization's needs, you might have a single Scrum Master on more than one Scrum Team, or the organization may decide to identify one person per Scrum Team to fulfill that accountability. Whatever your organization chooses, the Scrum Master should focus on the team's effectiveness, starting with the Scrum framework and eventually tackling adjacent organizational processes that impact the Scrum Team.
(To learn more about the Scrum Master accountability, signup for one of Rebel Scrum’s upcoming Professional Scrum Master or Professional Scrum Master II courses.)
Scaling for product teams
If you have three or more Scrum Teams supporting a single product, you might need to consider adopting a Scaling technique. Nexus is the most straightforward scaling technique in the industry. When it comes to supporting complex products, keeping it simple is best.
Nexus relies upon the Scrum framework, but it includes more events and an additional role to help teams manage dependencies and improve communication during the Sprint. To learn more about the Nexus framework, I recommend that you attend one of Rebel Scrum’s upcoming Scaled Professional Scrum courses. Taking this course with your entire Scrum Team delivers the best results.
Conclusion
A product is a vehicle that delivers value. Rather than defining a product by the technology or skills we need to deliver it, we define it as the thing we provide to our customers or end users. It might be a service, website, or physical product. Multiple Scrum Teams or Scrum Masters can support a product, but it should only have a single Product Owner and Definition of Done.
Product Teams consisting of three or more people might need to consider adopting a scaling methodology to manage communications and dependencies. To learn more about the Nexus framework, I recommend that you attend one of Rebel Scrum’s upcoming Scaled Professional Scrum courses.
Comentários