Back to Blog List

A Simple Exercise To Define The Product Of Your Scrum Team

Barry Overeem
(Netherlands)
November 29, 2021
Subscribe

A while ago, we hosted an experience interview with Roman Pichler, a product management expert specialized in digital products. He’s known from the various books he wrote: “Agile Product Management With Scrum”, “Strategize”, and “How To Lead In Product Management”, and the many tools he created, like the Product Vision Board, Product Management Framework, and the Product- and Sprint Goal templates.

During the one hour meetup, we covered a wide variety of questions, for example:

  • What if a Product Owner doesn’t have the mandate to make important decisions about the product?
  • What’s the difference between a Product Manager and a Product Owner?
  • How to create an outcome-oriented roadmap?
  • What’s your take on the Product Goal, that recently got included in the new Scrum Guide?
  • How to move from component-driven teams to feature-driven teams? — What should product leadership look like?
  • How can I help my team define success criteria?

Check the video to learn how these questions were answered.

In this blog post, we focus on one specific question that was raised:

“What is a product, actually?”

How this question is answered, impacts the entire Scrum team. It influences the Product Owner's role, determines the self-managing capabilities of the Scrum team, and the opportunities to ship fast and gather feedback from your stakeholders. In this article, we explain why this has such a big impact, and offer a simple experiment you can try with your team and its stakeholders to start a conversation about what your team’s product actually is.

Why It Matters

In our whitepaper about the Scrum framework, we explain that the Product Owner is someone who includes the perspective of what is valuable (and what is not) when it comes to the ambitions for the product. As the Scrum team spends its time and money working on the product, the Product Owner is there to make sure that this investment will return value to the stakeholders.

But what if the Scrum team doesn’t have a clear and shared understanding of what their product actually is? What if the product is a feature, a platform, or a technical component? What if they work on multiple products simultaneously? What if the Product Owner doesn’t really own a product, but only a small part of it?

The first and most important step to take is to create awareness and clarity on the type of product your team is building, and the sort of Product Owner you have.

  • If your Scrum team builds a technical component and has a dedicated Product Owner, then this person really is a “component-owner”;
  • If your Scrum team builds a platform that supports a product and has a dedicated Product Owner, then this person really is a “platform owner”;
  • If your Scrum team builds a feature that’s part of a product and has a dedicated Product Owner, then this person really is a “feature owner”;
  • If your Scrum team builds multiple products simultaneously for different customers and has a dedicated Product Owner, then this person really is a “portfolio owner”.

Such a Product Owner differs from how the Scrum framework has intended the role: someone responsible for the entire product. This doesn’t necessarily mean your Scrum team is doing everything wrong. But if your team focuses only on a specific feature, component, or platform, or tries to build multiple products simultaneously and has a dedicated “Product Owner”, chances are that the following happens…

The Scrum team struggles to formulate a Product Goal that gives them purpose, clarity, and guidance for the road ahead. Without a Product Goal, it also becomes difficult to create a Sprint Goal that helps the team align their work. Team members work mostly on their own items from the Sprint Backlog. This makes the Scrum events meaningless because instead of focused conversations on how to achieve the Sprint Goal, each event only becomes a boring status update.

Due to the many dependencies, the team has with other teams, departments, and suppliers, it’s not possible to ship fast. This prevents them from validating assumptions and learning if they’re on the right path. The dependencies also make it increasingly difficult for the Product Owner to make decisions. As a result, the “waiting column” of the team is packed with work. And large parts of the Sprint Backlog move to the next Sprint. Because there’s not much to show, the Sprint Review has lost its value as well. Not that it matters, the stakeholders were nowhere to be found anyhow. It’s no surprise that team morale is on a negative point as well.

In many organizations, the Product Owner ends up being an “order taker”. Taking orders from others in the organization, and only delivering them to the Scrum Team.

Now, I’ve painted a very negative picture with many assumptions. If your product is a feature, platform, component, or portfolio of products, chances are you’ll recognize what I describe, but it doesn’t have to be so negative. It is helpful to become aware of your situation and to consciously decide how to use Scrum. What is the type of product your team is building? What is the sort of Product Owner that suits best with that product? What team composition and skills do you need to include? What way of working would support your team the best? Is it Scrum? Or would XP, Kanban, or a mixture help you the most?

4 Simple Questions To Discuss

This is where a simple exercise comes into play, which is all about answering 4 questions, together with your team or stakeholders. You can make it a 15-minute exercise conducted after the Daily Scrum or a 2-hour workshop. I’ll offer you ideas for both. The four questions will help your team to start a conversation about the type of product they’re building. Once that becomes more clear, it also gets easier to explore the other questions I mentioned.

The 4 Questions are:

  • “What is our product?”
  • “What is our product, not?”
  • “What are parts of our product?”
  • “What is our product part of?”

Yes, I told you these were simple questions :) And I guarantee it will spare a powerful conversation!

Some ideas on how to use them

If you don’t have much time, simply share a digital workspace with your team and include the four questions. At the start of the week, ask everyone to include their ideas to answer the questions. With all the answers, you’ve covered the “What”-part. Use the Sprint Retrospective to bring the answers and to make sense of it (So What), and determine the next steps (Now What). In a creative way, you’ve used the Liberating Structure “What, So What, Now What”.

Other Liberating Structures we can recommend you to use are “Shift & Share”, “1–2–4-ALL”, or “Conversation Cafe”. All of them will help you to start a structured conversation with your team about what type of product they’re actually building. Make this a starting point to become aware of how it impacts Scrum, and what might be necessary to change in order to use Scrum more effectively. All of this shouldn’t be done for the sake of Scrum only, but because of the consequences, we described earlier.

Other DIY workshops to consider are…

If your team would benefit from having more clarity on the product they’re building, consider using the following do-it-yourself workshops. The following workshops include fully prepared strings of Liberating Structures and a step-by-step explanation of how to use them.

Closing

In this article, we explain why it matters to have a shared understanding of the product your Scrum team is building. It’s tricky to assume everyone has the same idea of what the product should look like and the features it must contain. We offer a simple experiment you can try with your team and its stakeholders to start a conversation about the product and clarify potential misunderstandings. Give it a try, and let us know the results!

What did you think about this post?

Share with your network