Scrum is a lightweight framework for solving complex problems. Therefore, the mechanics, as shown in the next picture, are relatively easy to understand:
It's the Scrum Master's job to bring the Scrum framework to life. And yet that is no guarantee that the product will be successful. It is the Product Owner's job to maximize the value of the product. There are many factors why some products are more successful than others. There is often a belief that determination, brilliance, the right timing and great ideas are enough to be successful. In my experience, there is another important success factor:
Is the Product Owner able to exploit the benefits of Scrum?
Before I present 5 important elements, first a few basics:
Fundamental underlying principles of Scrum are
- Empiricism with its 3 pillars: Transparency, Inspection, Adaptation
- Self-management: the team decides internally who does what, when and how.
At the same time, there are various complementary practices outside the Scrum framework because they are context-dependent and differ greatly depending on the context in which Scrum is used.
Five elements to maximize value creation
(1) Steer by providing direction
First of all, the Product Owner needs an understanding of the problems that potential customers try to solve and how one can generate business results with a solution for these potential customers. Product Owners need to talk to potential customers/users and observe potential users at work.
This understanding can be expressed in terms of a product vision, business model, or Product Goal. In the context of Scrum you need a strategic Product Goal from which you derive the Product Backlog.
At this point I am often asked: What is the difference between product vision and Product Goal?
- A product vision describes the purpose/benefit of a product and the ambitions it aspires to. It is the north star of the product throughout the product's life cycle. As shown in the picture, a product vision is a complementary practice and therefore optional from a Scrum perspective.
- A Product Goal describes a future state of the product. Like all good agile goals, it is specific and measurable. The product goal gives us more clarity and focus than the product vision. At the same time, the Product Goal is the minimum that a Scrum Team needs to get started with Scrum. Once a Scrum Team has met or abandoned a Product Goal, they move on to the next Product Goal.
Even without a clear direction, employees will find a way to stay busy, but success then becomes mere chance. In addition, it will be very difficult to move in the same direction and motivate/inspire Scrum Team members and stakeholders.
This is where the Product Owner can shine, it is their job to actively shape a direction.
(2) Create at least one usable Increment per Sprint
All necessary work to achieve the Product Goal takes place within Sprints. It is very tempting to only create technical designs (e.g. architecture diagrams) or product designs (e.g. mockups or wireframes) during a Sprint. The problem is that such designs are not valid until they have been proven in a usable Increment. In complex environments, we often experience feasibility surprises and need to figure out what is feasible and what is not. Therefore, if we only create designs in the Sprint, it could be a waste and it would deprive us of the opportunity to get feedback in the Sprint Review. Even if stakeholders were able to read design papers, only feedback for a usable increment gives us deep insights and generates helpful discussions on how to move forward.
A typical misperception is that many believe you can't create a usable Increment in the first sprint. Let me debunk that. I worked with a Scrum Team on Enterprise Warehouse Management. Our first Product Goal focused on inventory management and self-driving, computer-controlled forklifts. In the first Sprint, we built a very simple feature so that an Inventory Manager could control a forklift and get back some basic data like the type of forklift and its current position. It required a simple architecture and minimal product design to bring this feature to life. That then helped us to have a fruitful discussion with stakeholders about what to do next.
Of course, the entire Scrum Team decides in Sprint Planning what might be possible to achieve in this Sprint. Here the Product Owner can influence the formulation of the Sprint Goal via the top entries in the Product Backlog.
(3) Collect facts from productive usage frequently
Gathering facts from productive environments is the only way to find out whether a usable Increment really creates value for the customers and to validate assumptions. Unfortunately, many Product Owners are often unaware of how many assumptions they operate on. The longer they wait to get a release out, the greater the risk that they will invest in the wrong direction until they can no longer keep up with the competition.
Frequent releases are a competitive advantage that can help get a head start or help catch up. Admittedly, being able to release frequently is not easy and depends on a number of factors such as culture, tools, level of automation and internal processes. A release decision is a business decision and rests with the Product Owner. It is the responsibility of the Scrum Team to enable frequent releases. This discussion should take place in the Scrum Team, whereby the Product Owner can actively participate in the discussion for an investment in improving processes. At the same time, it is important to choose metrics in order to be able to make fact-based decisions. Here, the EBM framework by scrum.org may help us.
(4) Apply what you have learned in a timely manner
Feedback and data from productive usage help us to learn and correct course. In a complex domain more is unknown than known, and so we are constantly getting new insights, new facts, and knowledge. We incorporate these into the Product Backlog as soon as possible to create transparency and avoid waste. A product vision is also adjusted as soon as we have new knowledge. Nothing is ever set in stone!
Refinement of the Product Backlog is a process in which the Product Owner and the developers further refine Product Backlog items in order to come to a common understanding. Techniques such as User Story Mapping or Impact Mapping help to focus on adding value for customers and for our organization. These techniques are fast, visual and collaborative.
Refinement of the Product Backlog is context sensitive, and each Scrum Team has to figure out what level of detail and how often they need it. This is where the Scrum Team's self-management comes into play, and the Scrum Team learns best through experimentation, inspection, and adaptation.
(5) The whole organization respects the decisions of the Product Owner
If product owners' decisions are overruled by stakeholders, this can lead to the following problems
- The Product Owners cannot live up to their responsibility to maximize the value of the product
- The stakeholders very likely do not have all the facts and insights. This typically leads to suboptimal decisions, political games and delays.
- It can cause frustration in the Scrum Team because it hinders their self-management and demotivates them, especially when they have more facts and insights.
It is therefore essential that the decisions of the Product Owner are respected by the entire organization. Easier said than done. A Product Owner should speak the language of the stakeholders, involve them in the decision-making process in a meaningful way, such as in the Sprint Review, and earn the trust of the stakeholders. A Product Owner gains trust e.g. by giving the stakeholders the transparency they need and through good results.
Takeaways
For a Product Owner to maximize the value of a product with the help of Scrum, it is important that the empirical process and self-management of the Scrum Team is lived. The Product Owner has an active role in bringing the following five elements to life:
- Steer by providing direction
- Create at least one usable Increment per Sprint
- Collect facts from productive usage frequently
- Apply what you have learned in a timely manner
- The whole organization respects the decisions of the Product Owner
If you want to learn how a Product Owner:in effectively applies these principles, the following training is ideal for you: