“Product Owner” Is the Most Misunderstood Role in Scrum

By Willem-Jan Ageling

Most adaptations of the Product Owner function invalidate the Product Owner role

Image by Igor Link from Pixabay

Scrum is all about creating products of the highest value in complex product environments. Here’s why:

“In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done.” — The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka

If you are unfamiliar with this quote, then it may surprise you that it is from 1986. It is 34 years old. It comes from the paper that introduced the first concepts of Scrum: The New New Product Development Game.

Since then the world only became vastly more fast-paced, more unpredictable, more complex. Products that used to be popular last year have become obsolete by now. What will be successful next year, nobody knows. With that, long term detailed planning is ineffective. The sequential approach to developing new products has become even more nonsensical than in 1986.

Still, many organisations have not come to realise this. They have tailored Scrum to fit into their traditional processes. The role that suffers the most from this is the Product Owner. Development Teams can have some sort of autonomy in their Sprint bubbles. But Product Owners often are a mere mixture between a Project Manager and a Business Analyst. They ensure that the Development Team knows what to do and aim to follow the Product Roadmap. Rather than actively working to create a product that fulfils the needs of the stakeholders, the Product Owner follows a roadmap defined by others.

By performing these activities, the Product Owner role becomes diluted. As a result, it is a shadow of what it should be. The Product Owner role entails far more responsibilities than many companies believe.

Scrum Guide ambiguity

It doesn’t help that the Scrum Guide is ambiguous about the Product Owner role. It starts well:

“The Product Owner is responsible for maximizing the value of the product …” — Scrum Guide 2020

But then it adds:

“… resulting from work of the Development Team.” — Scrum Guide 2020

This is where the confusion starts. What does this phrase even mean? It is easy to read this as ‘making sure that the Development Team delivers according to a roadmap defined by others, translating the roadmap into the Product Backlog.’ Many organisations work this way. A Product Manager determines the product roadmap. Product Owners update their Product Backlogs to feed their teams with items for their component. They don’t own a product, they manage a component.

This is also how it often works with SAFe and other similar scaling frameworks.

Companies that work like this ignore the very reason to use Scrum.

The core of Scrum

“The shift from a linear to an integrated approach encourages trial and error and challenges the status quo. It stimulates new kinds of learning and thinking within the organization at different levels and functions.” — The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka

This is another 34-year-old quote that captures the core of Scrum. Empiricism is the foundation of Scrum. This is directly related to ‘trial and error’. In the world of empiricism, there is no place for detailed and static long term roadmaps. Product Owners need to find other ways to feed the Product Backlog. They need to maximise the value of the product by making the right calls on what to work on next. Scrum’s empiricism is crucial here. Especially the feedback from stakeholders at the Sprint Review.

The importance of the Product Owner

In a complex environment, it is the Product Owner who processes all feedback on the product. She/he does so by translating feedback into a Product Backlog ordered by possible value. The Product Owner needs to ensure alignment with many different stakeholders. They can be customers, users, sales, operations, infrastructure, architecture. She/he also needs to review the timeline, budget, potential capabilities and marketplace of the product. The Sprint Review is the logical place to do all this, but the work of a Product Owner exceeds the world of Scrum.

The Product Owner should drive the direction and growth of the product, with the help of the rest of the Scrum Team and the stakeholders.

Component Owners vs Product Owners

Earlier in the article, I mentioned how Product Managers create a product roadmap. The product roadmap is input for multiple Product Owners and their Scrum Teams. Each Product Owner works on a component of the product. This means that she or he is a Component Owner, not a Product Owner. This is a Scrum anti pattern.

I already mentioned that this setup is ineffective in a complex product environment. You can’t make detailed long-term roadmaps. But there’s more to it. The Component Owners may have a good view of their component. But they don’t see the total picture of the product, the sum of the components. With that, they are not in a position to decide what item from the component is the most important compared to the other components, or for the product as a whole. Only the person that has the total oversight can do this. In this example, no-one has this oversight. The Product Owner responsibilities are split between the Product Manager and the Product Owners.

Product Owner role vs Product Owner function

Scrum introduced a couple of roles, the Product Owner and the Scrum Master. Quickly organisations started to create job functions called Product Owner and Scrum Master. On a small scale, role and function are often the same. But things often go wrong on a larger scale when more than one team works for the same product. There are two ways to wrongfully creating a Product Owner function. Often you see a combination of the two:

• Some organisations believe that every Scrum Team should have a Product Owner. They have multiple Product Owners per product. Together, they own the product.
• Other organisations have a Product Manager for the end responsibility and Product Owners on ‘Scrum level’. Here Product Owners don’t even have the final say over their Product Backlogs. This is the Product Manager’s call.

Both adaptions of the Product Owner function invalidate the Product Owner role. In the first example, there should be only one person responsible for the product:

“The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.” — Scrum Guide 2020

Note that there is only one Product Backlog for a product and one person should have end-to-end accountability. One person should have the role of Product Owner.

In the second example, there’s one person in a position to have the end responsibility. The Product Manager should understand that she/he should embrace the Product Owner role. The people with the Product Owner function are important members of the Development Team. They translate the needs and expectations of product into a language understandable for the Development Team. But they don’t have a Product Owner role.

The power of the combined Sprint Review

There’s another related and important topic, the Sprint Review. This is the event where Scrum Teams and stakeholders discuss the current state of the product. This results in clear directions on what to do next. When 10 teams all help to create a product, how are you going to reach all your stakeholders with 10 Sprint Review events? The simple answer is: you won’t.

Instead, the 10 teams should have a combined Sprint Review, guided by the person with the true Product Owner role. In my example, this is the person with the Product Manager function. At such a Sprint Review, all teams together discuss with stakeholders.

Only a complete Increment — the latest state of the Product — is valuable to inspect. Also, findings from stakeholders are easily shared and discussed with all involved development teams. 10 separate Sprint Reviews that all tackle specific components can’t be this powerful. Also, having one event discussing the product is bound to draw key stakeholders more than the ones touching only aspects of it.

Value the Product Owner!

In complex product environments, a Product Owner and the Development Team(s) should be working together to maximise the value of the product by creating an Increment and inspecting it, learning from it. This does not come across well enough in the Product Owner section of the Scrum Guide. If you isolate this section, you miss out on empiricism completely. What’s more, if you only take into account the Product Owner passages of the Scrum Guide, you won’t find entries discussing empiricism, the heart of Scrum.

The Product Owner role is open for multiple explanations. As a result, some Product Owners only manage the Product Backlog while other Product Owners are responsible for the product vision and strategy.

A major issue arises when bringing traditional product delivery methods into the mix. Conventional delivery methods do not cater to complexity. It is dangerous to assume that portions of these methods mix with Scrum. Instead, they can lead to disastrous side-effects.

For Scrum to work, realise why it exists. It is there to create products of the highest value in complex environments. To succeed, a Product Owner should be the one with the final voice on what should happen next to the product utilizing a Product Backlog. The Product Owner should own the complete product, not components of the product.

The Product Owner will get the best results in a Sprint Review with all the Scrum Teams working on the product. Such an event will inspect the complete and integrated product Increment. This allows for high-value discussions and decisions.

The Product Owner role is very much misunderstood and misapplied. It is the most underrated role within Scrum. This is a role that in theory entails far more responsibilities than what you see happening in practice.

Don’t Waste Your Sprint Review. Make It Bigger Than Just Your Sprint

By Willem-Jan Ageling

From https://www.pexels.com/@skitterphoto

I love Sprint Reviews. At this event, empiricism works full throttle. The Scrum Team has added new potential value to the product Increment. Now the team and its stakeholders inspect the Increment and discuss what to do next.

The Sprint Review can be a powerful event to influence the direction of the product. But often Product Owners and their Scrum Teams waste excellent opportunities. They are in a vicious circle and only discuss the latest additions to the products. The stakeholders appear out of courtesy, not to help improve the product. In this unfortunate scenario, the Sprint Review is relegated to be just a demo or a status report.

There is more to a Sprint Review than that. The Sprint Review is the place to provide feedback on insights from what the team built. Also, it’s the place for stakeholder feedback on trying the released version of the product.

This is important. You want your Scrum Team to work on the most valuable stuff in the next Sprint. Help them do so with a high-quality Sprint Review.

This is what I am going to address here and now.

Uncovering the potential of the Sprint Review

To uncover the true potential of the Sprint Review, let’s start with assessing why it exists:

“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.” — Scrum Guide 2017

Many read this quote as:

“We show what we have created during the Sprint and gather feedback from our stakeholders about it”.

But this is not what the quote states. Let’s unpack this a bit more and see what an Increment really is:

“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” — Scrum Guide 2017

Many believe the Increment is only the sum of all the Product Backlog Items completed in the Sprint. But that is not the case. The Increment is all existing features plus the new functionality you added during the Sprint. It is the whole product, including what is new. It is the new product update to be released whenever the Product Owner wishes to do so.

When you realize this, you will not limit the discussions to what the team did in the last Sprint. With that, it makes the Sprint Review interesting for a larger audience.

New insights to the product can come from all kinds of places, not only from a demo during the Sprint Review.

Here are some examples of what I mean:

• The team repaired errors in the displayed calculations. Only a small part of your target audience will be interested in seeing this. If your Sprint Review focuses on this only, it falls short on what it could establish.
• The work from the Sprint can have an impact on other — already released — functionality. This without you realising. By demoing and discussing the complete product Increment you can uncover this. Stakeholders may have insights into the impact you never realised before.
• A stakeholder wants to discuss functionality created a few Sprints ago. They recently received positive customer feedback about it. This may be important to further uncover and exploit.
• A stakeholder wishes to discuss functionality created a few Sprint ago. Only now it turns out to be faulty.
• There are new market developments and the product needs to be able to cope with them. A new payment method is becoming very popular and your product needs to be able to use this method to stay relevant.

At the Sprint Review, discuss everything new about the complete product Increment.

In a complex environment, it is important to factor in all new information. It can all impact the decisions on what to do next. Scrum Teams work in complex environments. When you get a good sense of how the increment is working and respond to new information in a Sprint Review, you are adopting the best available tactic in this kind of environment.

“What has happened should be used for forward-looking decision-making.” — me, slightly adjusting a quote from the Scrum Guide 2017

Lessons for an effective Sprint Review

When you ensure the discussions tackle the complete product Increment you allow for strategic product decisions. As a result, the Sprint Review becomes important for senior stakeholders too. The Sprint Review turns into the Steering Committee for the product.

I worked as a Scrum Master for many teams over the years. I have identified two lessons with true stakeholder involvement at the Sprint Review:

Lesson 1: Discuss the complete product Increment. This increases the chances of getting important stakeholders to join the event as they can bring meaningful insights to the table.

Lesson 2: Ensure your essential stakeholders attend the Sprint Review. Allow them to discuss the complete Increment. It will turn the Sprint Review into the event where major product decisions happen. These product decisions impact the Product Backlog.

Both lessons strengthen each other!

Below are three real-life cases to clarify the lessons.

Example 1 — Discuss the complete increment

We made sure to discuss the complete product Increment all the time. At first, only the Scrum Teams and a portion of the stakeholders participated. But soon word spread how impactful the discussions about the product were. Then more stakeholders joined. This included people that were several layers higher in the organisation and people that used the product daily. The Sprint Review made a separate product roadmap meeting redundant. All potential participants for such a meeting were in the Sprint Review already. Decisions didn’t need another discussion.

Example 2 — Essential stakeholders attend the Sprint Review

Another team built a fraud detection product from the ground up. Right from Sprint 1 all essential stakeholders — including the users and directors — were involved in the Sprint Review. We looked at what the team built during the Sprint, new ideas and the actual usage of the product until now. We did not limit the discussion to only include work completed during the most recent Sprint. The Sprint Review was where we had everyone in the discussion. Based on the Sprint Review results, we always could work on what mattered most. The financial regulators of the Netherlands considered our fraud detection product to be best in class.

Example 3 — Failing to keep the momentum

A third team started their journey well. They had a daunting objective. They needed to create a new product using promising but unproven technology. The first Sprint was all about showing they could create such a product. So they built a rudimentary MVP. They succeeded to do so and the Sprint Review was a major success. But after this, the team went on to only demo the new functionality. More and more stakeholders skipped the event. They weren’t interested in these updates and missed the big picture. After a few Sprints, the team hardly got something useful from the Sprint Review.

Scrum Patterns and feedback beyond the Sprint

I love the Scrum Patterns. They are a set of best practices that help explain the rationale behind Scrum. Whenever I stumble upon something new for me as a Scrum Master, I tend to inspect the Scrum Patterns for more insights. I failed to find this for my experiences about the Sprint Review. But, I found a snippet that appears to contradict what I experienced:

“Many Scrum adherents view the Sprint Review as the main mechanism of agile feedback in Scrum, bringing to mind the usual forces of emergent requirements and market changes, change in business conditions, and so forth. There may be a bit of that. But a Product Owner and other stakeholders are unlikely to always be able to assess, in a three-hour meeting (isn’t it 4? — WJA), whether a complex product increment really does meet the intended need or not. More realistic and honest insight comes from trying to use the product in a more realistic application setting, over a more protracted period of time.” — A Scrum Book, Sprint Review

I agree that you can’t assess everything about the product in the timespan of a Sprint Review. But the most time-consuming parts (building the product Increment, gathering feedback from product usage) happen before the event. The Sprint Review is the place to share this feedback and then discuss insights based upon the observations. I argue that there’s plenty of time to do this at this event.

The Sprint Review is the place to provide feedback on insights from also trying the product over a protracted period of time. If the Sprint Review isn’t, there needs to be another meeting. I believe this would be unwise:

“Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.” — Scrum Guide 2017

Maximize the value of the Sprint Review

In a complex product environment, you base decisions on what you know. Even though you only have fragmented knowledge. Sometimes information about a certain change only arrives 3 months later. Don’t let it stop you from bringing it up at the Sprint Review.

There shouldn’t be any ‘we already passed this stage’ mentality. That is traditional waterfall thinking.

Scrum Teams work empirically. This means we learn from new information, and use it to influence ideas about next steps. Regardless where it comes from.

A Sprint Review can last 4 hours. Often though, the event is way shorter as it is a demo only. Perhaps, the team gathers some feedback about this demo. Teams that do it like this waste an opportunity to gain the latest insights on the product. They fail to have the best possible view on what to do next.

Shift the focus from output to outcomes. The Sprint produces an output, the outcome may come later. By shifting focus you can discuss the actual impact of your product.

• Discuss the complete product Increment. Include the new learnings from the functionality you built and shipped earlier. It will allow stakeholders to bring information about the product to the table. Topics like actual usage or user experience.
• Have essential stakeholders at the Sprint Review. Allow them to discuss new learnings about the complete product Increment. The Sprint Review could then make other strategic product meetings obsolete.

These two practices strengthen each other.

These lessons may impact the way you facilitate the event. You may divide the event into slots to allow people to attend the parts they wish to be at. Who says everyone needs to be there for the whole four hours? Having said this, the best decisions come with all the stakeholders together. But, there are options. There’s no one good way.

SAFe’s Scrum vs Scrum According To the Scrum Guide — They Are Not the Same

By Willem-Jan Ageling

A comparison of two different beasts

The Scaled Agile Framework (SAFe) exists to “to enable the business agility that is required for enterprises to compete and thrive in the digital age.”— scaledagileframework.com/about. 

Organisations adopt SAFe to align multiple teams working on the same solution or program. SAFe is one of many ways to scale.

The Agile teams in a SAFe environment can make their own choices from the many Agile practices to deliver valuable software:

“SAFe teams use Agile practices of choice based primarily on Scrum, Kanban, and Extreme Programming (XP) to improve their performance.” — SAFe 5.0/Agile Teams

Many Agile teams choose to work with Scrum. However, the above link doesn’t point to the Scrum Guide version of Scrum. It points towards a SAFe page discussing “ScrumXP”. This is a hint that ScrumXP is the preferred way of working within SAFe.

ScrumXP is the standard, adapted version of Scrum in a SAFe environment.

ScrumXP differs from Scrum according to the Scrum Guide. Often this is due to elements of XP, sometimes not. It is true that Scrum is an add-on framework. Introducing XP practices in Scrum is totally in line with Scrum and often happens. However, SAFe takes it further than adding XP to Scrum.

SAFe combines Scrum and XP frameworks to create its own ScrumXP process as part of its framework. SAFe gives Scrum and XP terminology new meanings and structure. This reduces the transparency over what Scrum (and XP) is. This article aims to clarify to practitioners the differences between Scrum as defined in the official Scrum Guide and ScrumXP as defined in SAFe.

Image by Arek Socha from Pixabay

Definition and usage

“ScrumXP is a lightweight process to deliver value for cross-functional, self-organized teams within SAFe.” — SAFe/ScrumXP

SAFe uses Scrum to guide team agility and XP for technical guidance.

Scrum has a different purpose than ScrumXP:

“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — Scrum Guide 2017

I find it interesting to note that the Scrum Guide says this:

“Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.” — Scrum Guide 2017

There’s an important difference between a process and a framework. A process is more directive than a framework. As a result, the different ways to look at ScrumXP and Scrum say something about the use of the approach.

Scrum is a framework to tackle complexity and deliver value while ScrumXP is a process to deliver value with SAFe. This is not the same.

ScrumXP is something you run as a container in SAFe. It’s a process within SAFe and not supposed to change how you work.

Composition and characteristics of the team

While Scrum has Scrum Teams, Scrum XP has Agile teams. An Agile team using ScrumXP self-organises, self-manages and is cross-functional. Scrum doesn’t mention self-management. Both approaches stress the importance of teams finding their own best way to deliver value, based on the intent or the goal. Both also acknowledge that having this team composition can help raise productivity and enjoyability.

Product Owner and Scrum Master

ScrumXP has two special roles: Scrum Master and Product Owner. The Scrum Master focuses on the effective use of ScrumXP and on removing impediments. The Product Owner focuses on what the Agile team will build.

Both roles in ScrumXP deviate a lot from the Scrum role. You can read more on this in the detailed articles discussing the Scrum Master and the Product Owner.

The Sprint/Iteration

SAFe uses a different word for the timebox in which the team builds an Increment: Iteration. This is just like XP. Apart from that, the objectives of an Iteration are the same as the objectives of a Sprint in Scrum: producing an Increment that delivers value.

Sprint/Iteration Planning

The length of a ScrumXP Iteration planning is four hours or less. The Scrum Sprint Planning is eight hours for a one month Sprint and less for shorter Sprints. Both with ScrumXP and with Scrum, the Product Owner brings forward what should be achieved and the team decides how much they can do and how they will build it.

Both planning events revolve around defining a goal for the Iteration/Sprint and selecting Stories/Product Backlog Items. ScrumXP starts with creating an Iteration Backlog and then defines an Iteration Goal. Teams commit to meeting the goal and finishing the Stories on the Iteration Backlog.

With Scrum, however, teams first discuss the Sprint Goal and then creates a Sprint Backlog, which has the selected Product Backlog Items to meet the Sprint Goal and a plan for delivering the Increment and meeting the Sprint Goal. Teams commit to finishing the Sprint Goal and the Sprint Backlog is a forecast only as it can change to allow inspection and adaptation to optimise the chances to meet the Sprint Goal.

As you can see, there are pivotal differences between ScrumXP’s Iteration Backlog and Scrum’s Sprint Backlog.

But ScrumXP teams commit to more:

“Some teams break each story into tasks. […] As team members commit to tasks, they reduce their individual iteration capacity until it reaches zero.” — SAFE5.0/Iteration Planning

Here ScrumXP even discusses commitment to individual tasks. Scrum also mentions breaking up work in units of one day or less. However, teams or individuals do not commit to them. This would violate the rules of Scrum where the Sprint Goal is the true north of a Sprint, not the Sprint Backlog.

ScrumXP has detailed guidelines on how to facilitate an Iteration Planning, like:

• An Iteration Planning agenda;
• How to estimate (using story points);
• How to establish capacity.

Scrum does not have these details. It merely discusses that Sprint Plannings have two parts:

• What can be done?
• How will it be done?

It is up to the Scrum Team to determine how to do it.

Daily Stand-Up/Daily Scrum

SAFe again uses the XP term for the daily alignment event. However, this doesn’t change the purpose of the event, to understand how the team is progressing towards the Iteration/Sprint Goal and adapt if this increases the chances of meeting the goal. SAFe also adds some XP practices to the event. With that, the event is more prescriptive than the Scrum Guide equivalent.

In SAFe, the Scrum Master ensures that the event doesn’t take more than 15 minutes. The Scrum Guide only brings forward that the Scrum Master teaches the team to do this.

Iteration Review/Sprint Review

With SAFe, the Iteration Review is a demonstration to the stakeholders of the things they completed. It is an opportunity to inspect if the Increment is working according to stakeholders expectations and to adapt if this is needed. The team also discusses progress towards the Program Increment objectives. The timebox is one to two hours.

Scrum’s Sprint Review, however, entails much more. This Scrum event with a maximum timebox of 4 hours is an opportunity to inspect if the product is heading in the right direction and discuss what to do next, adapting the Product Backlog if needed:

“The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,

Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.” — Scrum Guide 2017

SAFe pushes this to the Inspect & Adapt event, at the end of the Program Increment. With that, an important aspect of Scrum’s empiricism falls outside of a Sprint/Iteration and outside of Scrum. It delays feedback, impacting business agility.

Iteration Retrospective/Sprint Retrospective

This event basically has the same objective for both ScrumXP and Scrum. ScrumXP puts forward that the timebox should be one hour or less. Scrum discusses that it should be three hours or less.

ScrumXP is more prescriptive than Scrum, but this should be no surprise anymore. Other than that, there’s not much difference.

Not in ScrumXP

The Scrum Guide has items that are not in ScrumXP. Here follows a list.

Scrum Values

Scrum puts the spotlight on the values of commitment, courage, focus, openness and respect. ScrumXP doesn’t have these values. SAFe has four values: alignment, built-in quality, transparency, and program execution. These are by no means the same as the Scrum Values.

Empiricism

ScrumXP doesn’t mention empiricism. The Scrum Guide considers empiricism to be the foundation of Scrum. It is a vital piece of the puzzle to understand Scrum.

The main article of ScrumXP also doesn’t mention transparency, inspection and adaptation, the three pillars of empiricism. Inspect and adapt are terms that you will find other pieces of the SAFe puzzle, but you will hardly find it in the context of ScrumXP.

By removing the emphasis on empiricism, ScrumXP indeed becomes a process to deliver product Increments. Whether they are of value is addressed later, at the end of the Program Increment. ScrumXP is not a framework to address complex products like Scrum is.

Agile Release Train

ScrumXP also has topics involving the Agile Release Train and coordination between teams. I think it is obvious that Scrum doesn’t discuss this.

Endnote

ScrumXP, SAFe’s delivery process inspired by Scrum and Extreme Programming, is not the same as Scrum as defined in the Scrum Guide. ScrumXP isn’t the typical blend of Scrum and XP.

Most notably, ScrumXP doesn’t mention the Scrum Values and Empiricism, both pivotal for Scrum.

An Agile team, the ScrumXP equivalent of Scrum Team, is part of a bigger picture. Their prime objective is to deliver Increment of valuable products in line with the Program Increment Objective. A Scrum Team has a different purpose, addressing complex products while delivering value.

SAFe is the framework and ScrumXP is a process, part of this framework.

As a result, ScrumXP has a different expectation from an Agile team, Product Owner and Scrum Master.

All in all, ScrumXP and Scrum are totally different. This should be no surprise as they serve different purposes.