Prioritization and working with your product backlog

What is a backlog, why do you need it, how to make and manage it properly.

Check out the latest addition to our series of publications on how to create and run a project. Our previous articles focused on fundraising for your startup, testing hypotheses, developing MVPs and ensuring PMF, as well as other helpful materials.

Our today’s agenda is all about the product backlog — what it is, why do you need it, and how to make and manage it properly.

Your backlog is a sorted list of issues for your product team. The most important ones are those to handle anytime soon — they top your list. The higher an issue is on the list, the better it is elaborated and in more detail it is described. A backlog should be described in plain language, with no technical specifications, so that every team member understands it. It is important to find a reasonable balance between a clear description and superfluous details. Be sure to save your own time and developers’ time.

How is a product backlog different from a sprint backlog?

The main difference is that a product backlog is a complete list of requirements and tasks for developing that product. It is a framework that leads you toward your goal.

A sprint backlog helps visualize the work process toward short-term goals. It is a list of issues that need to be dealt with at specific development stages in order to implement one of the product’s elements. A sprint backlog is created by the scrum team, not the product owner. The participants generate a list of tasks at the start of each work phase.

For the sake of convenience, all issues can be classified as follows:
- Bug is an error, defect or glitch in a program or app. It implies that there is something wrong with the current product and it must be fixed.
- Feature is a new function or a feature of a program which has not been previously approved, but builds up its functionality. Its purpose is to improve program/app characteristics or simply attract users’ attention by its unconventional function.
- Epic is some overriding theme for a group of issues. It implies a large amount of work or a large user story that cannot be implemented in a single sprint. For example, a customer wishes to be able to find friends for rides in a motorcycle app and organize such rides with route records.
- Idea is an unprocessed concept, which is not yet detailed.
- Tech task is an issue that has no product value, but offers a technical benefit. For example, moving to a different database.
- Sub-task is a smaller task, which represents a tool for addressing the main task.

Most IT companies use Jira to create backlogs, although there are many other systematization tools. Jira is the one offering a fairly convenient hierarchy of “entities” and their prioritization. A backlog contains such entities that cause changes in the program code. The main purpose of the backlog is to streamline the distribution of a team’s resources.

Typical Jira hierarchy: Project/theme — epic — story — sub-task

An epic is a group of tasks, a big theme. Also, an epic can be used as a way to label a story or a product tag. A story is a user story, a requirement. It is a unit of functionality that makes sense to a user in its entirety. It is great if you can peg a story to Jobs to be Done. Sub-tasks for the most part have technical value.

Task specifications:

1) Task type:
- Bug
- Story/Task
- Epic
- Idea
- Sub-task

2) Task size:
- Story points (1–2–3–4–5–8-…) A task can be measured on the Fibonacci scale — the sequence of numbers that add up the two preceding numbers: 1, 2, 3, 5, 8, 13, 21…

1. very easy — a task that is dealt with in 10–15 minutes (e.g., repainting a button).
2. easy — a task that takes within 1 hour. You can handle about 10 such tasks during the day.
3. normal complexity — a task, for which you do not need to create anything, but it requires time to address. There may be two or three such tasks per day.
5. complicated — a task which calls for creativity and analysis. Such a task cannot be addressed in one or two days and calls for special preparation.
8. very complicated — a task that has no ready solution by the executor. It requires searching for a solution, doing additional research, trying various approaches to implementation. Such a task takes up an entire sprint.
And so on.

- Size (S-M-L-XL). The four relative task sizes.

Estimating the complexity of tasks in a backlog enables you to predict how much time it may take to complete the portions of a backlog. This estimate is required to identify the speed of your team. Determining the complexity of your backlog components is necessary to understand how much time it will take to implement the backlog components.

3) Priority (High-Middle-Low) is best used for bugs, since they are not homogeneous with tasks and it is important to rank them by importance.

4) Which theme they belong to:
- Epic
- Component (website/app/landing)
- Business objective (Objectives and Key Results )

5) Other
- Sprint ( which sprint they belong to )
- Label (tag) For example — programming, graphics, or game design.
- Version/release (in which version the task will be dealt with)
- Various dates (opening date, closing date, duration)

The lifecycle of a task is structured as follows:

1. Idea (inbox) — just a written idea
2. Developed idea — there is a detailed description, it is best that you describe it using the User Story.
3. Ready for development — a shaped idea with a detailed description. It also can be described in terms of the User Story where necessary.
4. Development backlog — described tasks are listed, but not yet designated for development.
5. In Sprint — tasks from the backlog designated for development and scheduled for the Sprint.
6. In development — a task is assigned to a responsible performer or a team.
7. Development completed — the task is completed and the result can be tested.
8. Tested — the task has been tested, bugs are fixed, where necessary.
9. In release — the task can be released to users.
10. Released — users can benefit from functionality.
11. Analysis — analysis of how users engage.

Backlog refinement

The backlog tends to grow uncontrollably — founders’ ideas, users’ suggestions, bugs identified by testers, additions from the team. You need to control this process and carry out backlog refinement in a timely and clear manner.

This involves:
- bringing current tasks up to date
- creating new tasks
- checking the objectives, re-sorting the middle
- work through immediate tasks:
1) clarifying the essence
2) decomposing
3) estimating labor input
4) revealing dependencies
- closing what can be closed.

Backlog refinement is usually performed once every 2–4 weeks with the team.

It is important to do this in a separate meeting isolated from current work planning, as it essentially constitutes preparations of the scope of future work. This meeting will “clean, sort out, organize” and then a sprint of prepared tasks is formed.

Where do tasks come from? Anyone in the company — a stakeholder or developer — can come up with an idea. The first thing to do is to describe the issue, rather than solutions. Product users are a permanent source of new issues, and it is important to have consistent feedback. But how will you decide which issues should be included in the backlog and how will you identify their value?

Prioritization is the main challenge in backlog creation. The need for setting priorities is due to the fact that resources are invariably insufficient to implement all potential ideas. All ideas must be evaluated in terms of certain indicators — economics (how much it saves or how much the company will make), coolness/benefit for the customer (according to the degree of expectation, e.g. must have) and complexity (similar to story points).

The general prioritization principle: MAX (Value/Effort).

Value can be distributed either on a scale from 1 to 5 or on a high/medium/low scale. Effort can be expressed in man-hours or in story points. You need to maximize the value inherent in your product at each point in time, given your limited resources.

There are many approaches to and methods for prioritization. They can all be divided into quality- and quantity-based. Some people feel more comfortable with quantity-based approaches and are backed by specific figures. For others, it is more effective to work with quality parameters if what you are trying to accomplish is not quantifiable or if this makes no sense in your context.

The best viable formula:
RICE prioritization: Max (reach x impact x confidence/ effort)

Reach — how many people will be affected by the feature, how many will be influenced. It is usually measured in percentage of the total service audience, although it can also be expressed in absolute figures.
Impact — the power of the impact, how much it will influence users. It is a relative value.
Confidence — the degree of your confidence in this information. It is expressed in percent.
Effort — labor intensity.

How you set priorities depends on the product, its stage, and context. In general, the power of impact on the product (users), labor input per task, time required for implementation, and the market situation are estimated.

When picking a framework for prioritization, answer the following questions:

- In which conditions do you prioritize tasks? In which development stage is your product? Which is more important at this point in time — growing the number of new users, increasing the average bill, or indulging investors?

- How much external interference is there in the prioritization process? Are your stakeholders engaged in backlog creation? If there is more than one, how does the prioritization process work?

- To what extent will prioritization rely on expert opinion rather than metrics? When using the RICE formula, you assign Confidence to information about a task. This is expert opinion, which may not always correspond to the facts. Or, when prioritizing, you seek advice from the executor — the developer who speaks about its relevance validated by their expertise, rather than metrics.

- Which metrics will you seek to reach? You should identify the main metrics at this stage of product development. For example, according to the AARRR method.
A: Acquisition — Visit site/landing page, Doesn’t abandon (stay 15 sec, 2+ clicks)
A: Activation — Happy 1st visit (views X pages, B clicks)? SignUp
R: Retention — Repeat visit
R: Referrals — Refer 1+ users
R: Revenue — Generates revenue

- What are your strategic objectives? — You might encounter a situation where your developer comes up with an idea to rewrite some part of the code, because the functionality has snowballed and you need to focus on the organization of the entire process. And you will have to decide which is more important to you in this situation — new features or the comfort and efficient response of your team.

A single specific framework is very rarely used. In most cases, it is a combination of several frameworks or one of your own, tailored to your specific environment.

Challenges that arise when creating and prioritizing a backlog:

- each task has MVP stages, and each envisages its own labor inputs
- team resources are not homogeneous (design, frontend, backend)
- there are dependencies between tasks (feature B is impossible without feature A)
- bugs and technical debt eat up some productivity
- priorities are constantly changing (this is agile)
- development time is always increasing.

The goal is not to set priorities and deliver them. The goal is to be constantly aware that what you are doing really builds your product’s value and works as expected. Prioritization should not be done on your own. For the exception of very simple methods, there will almost always be someone else engaged — customers, stakeholders or team members — because the product belongs to the team.

Despite the multitude of techniques and frameworks, you are the one to make the call. Connect them, make changes, create your own methods. Do whatever it takes to make it comfortable for your team to work and for your customers to benefit from a useful and valuable product.