Scrum Product Owner Activities - Explained

Scrum Product Owner is one of the most important roles in the Scrum development process. This is the person responsible for bringing products to life and inspiring the entire development team. The Product Owner maximizes the value of the product resulting from the work of the Scrum Team. In other words, the Product Owner solves users’ problems and helps businesses to succeed. Usually, there is a whole team involved to perform various Product Owner activities.

If you are not aware of the term Product Owner Activities, then you have landed at the right place. In this blog post, we will discuss Product Owner Activities in great detail with the help of easy-to-understand graphics and illustrations.

Solution Needs

Every user performs various activities either to solve problems or fulfilling needs and/or wants. These activities are called Goals. These goals can further be categorized into 4 types as shown below figure:

Solution Categorization

In recent years, Agile and the Scrum community have taken to Cynefin (Ki-NEV-in) as a means of understanding and explaining why Scrum is applicable in the creation of many solution and software development initiatives.

Simple

In this domain, mostly ‘Best Practice’ could solve most of our problems i.e., the product we create or the problem we face is so clear that it can be easily responded to with a simple set of instructions. It only needs a checklist to be followed. You do not need to structure the response-based Scrum roles and organize Scrum ceremonies. There are chances that it would only add overhead and confusion among the team. Traditional and sequential product development methodologies like ‘Waterfall’ are best placed here, as we’ll just do what we already know works.

Complicated

Solutions in this domain require special assistance, expertise, or additional advice through sensing and analyzing. Here we are dealing with known unknowns. It may also require team collaboration; however, it does not necessitate Scrum because we are not exploring the domain.

Complex

This is an exploratory domain with unknown unknowns, in which most software development initiatives occur. The Cynefin framework here implies that we must test the waters, analyze the outcomes, and adapt our next move based on feedback received and the knowledge created as a result of it. Scrum is an ideal candidate here to reap the benefits of small development cycles (Sprints or Iterations). The Product Owner (voice of the customer) is then well-positioned to decide what is the most valuable thing to implement in the next cycle in order to satisfy customer needs.

Chaotic

If you find yourself in a Chaotic domain, you have no choice but to act as quickly as possible to move backward (clockwise) towards the “Complex” domain. There needs to be something done that can help us accomplish this. Thereafter we can analyze the most important steps to keep ourselves moving. There is no scope for experimentation and exploration here to increase our knowledge so Scrum is largely inappropriate as survival is the primary requirement.

Disorder

In this domain, one could say that we are “lost”. As “Cynefin” is a “sense-making” or “data-driven” framework, if we cannot make any sense of our surroundings then it means we are in disorder. Without data, we cannot move into any of the other 4 domains to align ourselves. Scrum is not likely to help us because there is no information or knowledge there to guide us.

So, we have now understood how the Cynefin Framework helps us to make sense of our environment, and better understand Scrum’s applicability (i.e. where to adopt it and where to reject it).

What is Being a Product Owner?

In Scrum, the product owner is a role played by a single person or a group of people focusing on various areas as shown in below picture:

Product Owner’s Life

PO (along with the team) normally performs product discovery, refinement & prioritization, and delivery of the product/solution.

Product Discovery

What is Product Discovery?

As we know that the product requirements just don’t come from end-users. So, the Product Discovery Team needs to deeply understand their pains, needs, and wants in order to solve them.

This can come from user observations, discussions, listening, empathizing, and many other ways. At the same time businesses also want to have more ROI. So here PO with the help of the Development Team creates products and services that solve the above needs.

A Product Discovery Team is a group of people who can collaborate with the Product Owner. The team can consist of end-users, their representatives, sponsors, the development team, and any other person/group that can provide feedback.

Product Discovery Activities

Conceptual Story

The conceptual story helps the product owner identify differentiators in the product that solves user problems/needs and provides user satisfaction.

Every product must have a differentiator, otherwise, there are high chances of the product getting failed.

Impact mapping helps PO break down the vision into Actors, Activities, Constraints, and Releasable features as shown below.

Product Prioritization

Product Prioritization is the systematic process of evaluating the importance of work, requests, and ideas, to discard unnecessary practices and deliver customer value as fast as possible, with a variety of constraints.

There can be various models, methods, and matrices used to do the same.

Kano Model

Based on various prioritization techniques, below is a User Story Map of releasable features.

Product Delivery

Using various Scrum ceremonies, the Product Owner can effectively deliver Product Increment to the users. Those ceremonies are:

Conclusion

In this article we saw that the Product Owner is an essential member of every Scrum team. The primary goal of a Product Owner’s role is to represent the customer to the development team. To provide the solution to the customers and help the business grow, the PO manages, prioritizes, and makes the product backlog visible for future Product development using various techniques.

All product and company names are trademarks™, registered® or copyright© trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.