A Product Owner’s To Do List

Lately, we have been writing about the Planning Agenda a lot. Now it is time to explain the To Do list for the roles we have in ScrumOne.

There are four To Do’s  when it comes to the Product Owner’s involvement:

  • Cooperate with Developers and the Scrum Master on clarifying User Stories
  • Answer questions from the Developers
  • Set up the Sprint Goal
  • Fine-tune the Product Backlog


Cooperate with Developers and the Scrum Master on clarifying User Stories 

Here, we are talking about the Refinement, which can happen during the Planning. User Stories are being refined in the Refinement session, but some details may need to be further specified. After the Refinement session or Review, we can discover new information that could change how we view the work.

The Product Owner should explain the purpose of the User Story in a way that everybody understands it—including the Scrum Master.

We are all equally responsible for the User Story being clear, but it is the Scrum Master’s responsibility to make sure that it is.


Answer questions from the Developers 

In order to clarify the User Stories, the Product Owner has to answer any questions the Developers may have. If the Product Owner is not sure and does not know the answer, he can invite the correct person to come to the Planning who can provide the information. The Product Owner should be looking for the answers actively, and needs to always be willing to find them.


Set up the Sprint Goal 

Before we set up the Sprint Goal, we need to understand its meaning.

What is the Sprint Goal?

In our last article about Perfect Planning, we mentioned that the Sprint Goal is a vision of the end result.

It covers all the activity that takes place during the Sprint. It is a rundown of the functionality we are working on during the Sprint, as well as the strategy behind it.

So, how do we set up the Sprint Goal?

I use “we” because it is not just the Product Owner’s choice and idea. Sure, the Product Owner presents the idea of the Sprint Goal in the beginning of the Planning event so that Developers will know what they are going to work on during the Sprint, but the final Sprint Goal is ultimately defined mutually with the entire team.

It is a good idea to come to the Planning session with a Sprint Goal proposal already prepared. The Sprint Goal should also be presented to the stakeholders before the Planning event, during the Review, so they have an idea of the plan. Also, User Stories should be prepared for at least one Sprint ahead and ordered based on the idea the Product Owner has. From that idea comes the Sprint Goal.


Fine-tune the Product Backlog 

The Product Backlog is a living document, constantly evolving and changing based on the information the Product Owner obtains from the Stakeholders and Developers, the market situation, business inputs, etc. Over time, priorities can change.

During the Planning event, when Developers pull the User Stories into the Sprint, the investment one of the User Stories needs can be much bigger than expected. In reaction to this newly discovered information, the Product Owner can decide to rearrange the order of the User Stories and move the concerning User Story down in the Product Backlog or deprioritize it. It does not mean that once we clarify and estimate the User Story, we have to take it to the Sprint.


Stay tuned for our next article about the Scrum Master’s To Do list.


Thank you for reading!

You may also like:

A Developer’s To Do List

Ok, the Product Owner’s To Do List and Scrum Master’s To Do List are done, so the last one left is the To Do List…

A Scrum Master’s To Do List (Part II)

Ok, you already read about the To Do list for Scrum Masters, so why are we mentioning it again? Since the Scrum Master’s To Do…

A Scrum Master’s To Do List (Part I)

Our previous article in our Perfect Planning series was dedicated to the Product Owner’s To Do list. If you take a look at the ScrumOne…