Prioritizing tasks in the backlog: A case study from the perspective of a Product Owner.

Product Owner is a role in the scrum process. They are responsible for the business aspect of the project and/or product.

Knowing how to define priorities affects project success, team engagement, and the role of the leader. All projects, and especially the large and complex ones, require clear priorities. Easier said than done, right? Especially if every tasks seems to be priority number one and requires attention.

Some time ago, my team was reviewing the Agile process and was considering moving from sprints to Kanban. We asked ourselves the question: at what level should the product owner define priorities? Feature, Epic, or Story?

Solution Design Process

User Story
It is common knowledge that software developers work at the level of User Stories. They can also work at the level of a task, but what matters is the Story. This means that Product Owner (PO) sends and prioritizes the Story and the bugs.

It is possible for one Story to be divided into many Stories for reasons related to planning and dividing work between different software developers. In such a case, the Product Owner may be confused by the appearance of “different” Stories.

Epic
This is a set of work that can be divided into particular tasks called User Stories and is created on the basis of the needs of clients or users.

Feature (functionality)
Alternatively, we could let the Product Owner work at the level of functions, allowing software developers to continue work on User Stories. This means that the PO sends and prioritizes functionalities.

The problem with this approach lies in handling bugs—because bugs occur at the level of a User Story.

Process in example

We have reached a conclusion that the Product Owner is someone who has a wider
perspective and should go for Epics. Then they should move down to Stories. At this point,
depending on the functionality, priorities for User Stories start to appear. Let me give you an
example. Let’s say that we are developing the “News” tab on a website.
We can have the following Epics:

1. Adding news
2. Commenting on news
3. Sharing news

First, we need to work on the first Epic (adding news) because you cannot comment on or
share something that does not exist. The Product Owner needs to decide which of the other
two Epics is more important: commenting or sharing.
When the decision is made, Product Owner is at this stage:

1. Adding news
2. Sharing news
3. Commenting on news

Sharing news is more important. What is necessary to make all of this work? Division into
Stories.

1. Adding news:
   a. Add an item of news
   b. Update an existing item of news
   c. Delete an item of news
   d. Show an item of news
2. Sharing news:
   a. Share on website
   b. Share in social media
   c. Share by e-mail
3. Commenting on news:
   a. Add a comment
   b. Mark a comment as abuse
   c. Delete a comment
   d. Moderate a comment

Setting priorities

If we focus on the first Epic (adding news), we have four Stories, and the priorities are becoming clear. You cannot view, update, or delete something before it has been created, so adding an item of news is number one. Viewing, updating, and deleting come next.

Setting priorities now happens at two levels:
– Epics, to see a wider picture
– User Stories

At the level of Stories, you start to notice relations between them. This helps to set priorities in terms of Stories for software developers. In addition to that, setting priorities at the level of Stories allows the Product Owner to get some important elements of Features much earlier than others—they are able to view a number of functions at the same time.
Product Owners should not prioritize the tasks attached to User Stories because tasks are created and belong to software development teams that do the work and they know best what should be done and how in order to deliver a User Story.
Naturally, the method proposed above is a result of my experiences with working in a scrum team and is not necessarily an officially approved course of action.

Bibliography:
Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time