polygon
polygon

Biztech Blog

At the edge of technology
Scrum Product Owner Activities – Explained1

Scrum Product Owner Activities - Explained

By : Anirudh Zala

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_Needs
PO team brings various Solutions to fulfill the above goals, which can be either Product, Project, Service, Application, or a combination of one or more.

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.

Solution Categorization
Let’s go through the domains in a counterclockwise direction. We will begin with the Simple domain first.

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:

What is Being a Product Owner

Product Owner’s Life

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

Product_Owner_s_Life

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

Activity Purpose Actors Input Output Technique
Identifying Vision Define common goal to be achieved Product Discovery Team, Stakeholders Pains, Needs Wants Product/Solution Vision Elevator Pitch, Advertisement etc.
Market Research Finding user segments where the product is to be launched “” Vision Statement High Level Modules Conceptual Story, Impact Mapping etc.
User Research Validate the assumptions against users’ Goals (problems, needs, wants) Product Discovery Team, End Users and/or their Representatives User Goals to be validated User Stories User Experience Mapping, User Interviews, User Personas etc.
User Story Mapping Map user goals to product features and prioritize them based on goals, budget etc. Product Discovery Team, Stakeholders User Stories PB based on User Goals, Often prioritized Kano Model, Eisenhower Matrix, Impact Matrix, Opportunity Matrix
Story Detailing Add more details like flows, diagrams, mock-ups etc. and keep the PB Ready for execution PO, Stakeholders, Development Team etc. Product Backlog Prioritized Product Backlog Team Voting, Business Value Creation, Market Demand etc.

 

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.

Conceptual Story
Impact Mapping

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

Impact Mapping
Using the below impact mapping template, PO can document product impacts on vision

Impact Mapping-2
Other Product Discovery Techniques

Other Product Discovery Techniques

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

Kano Model
Eisenhower Matrix

Eisenhower Matrix
Opportunity Matrix

Opportunity Matrix
Impact Matrix

Impact Matrix
MoSCoW Matrix

MoSCoW Matrix
User Story Map Example

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

User Story Map Example

Product Delivery

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

Sprint Planning-1
 

Daily Scrum-1
 

Sprint Review-1
 

Sprint Retrospective-1

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.

Get Free Consultation

    ✓ 100% Guaranteed Security of Your Information