💆🏾 🗒️ 🎒 Backlog scoring and prioritization techniques 🧕🏿 👎🏽 🌺

Well, how are your isolation plans? Winter things removed? Have you watched the coveted movies? Have you read the dusty books? And, as always, there is no time for utilities. Come on, do not make excuses - for those who can’t make an hour to watch the video from our YouTube channel , we have made a digestible article. Have a conscience, just 15 minutes instead of 60 :)

Today we touch on product management and analyze backlog prioritization. Product management costs a little higher than project management: it is more about product management in general and is closely related to marketing. For a snack, let's look at scoring techniques and task assessment.

Situation

When there is a backlog, the manager needs to somehow prioritize it. Scrum says that the most important tasks from a business point of view should be the first. But there are two problems.

The first is a fair moment of subjectivism: often priorities are set the way the business owner wanders. to the head. But sometimes the owner can “hallucinate” strongly and carry frank nonsense, but be sure that everything is so.

The second problem: too many top-level stakeholders on the part of the business on large projects or in large companies. Each of them may have its conflicting requirements. If you collect, for example, five tops of a large company and ask them to prioritize their requirements, most likely everyone will argue that his tasks have zero priority, and they need to be done right now.

The good news is there are a few techniques that help in this case:

agree on priorities - choose what is more important and what can be postponed;
establish criteria for backlog prioritization (a little less subjective than someone’s hallucination - alas, it’s impossible to do without subjectivity).

Methods for Prioritizing Tasks

What does the backlog look like?

Backlog is a table. In one column - a list of something (some Wishlist), there is a column with an estimate (estimate) and there is a column with priorities. Priorities are some numbers, usually large. Large so that there are “holes” between the priorities, where you can add new tasks (or to easily change the priority).

According to the classics, priorities are set in terms of Business Value (business value) - what the business needs first of all, it will go to work in the first stage. But there are other ways of prioritization that are more convenient - especially if you have a bunch of motley tasks.

Story mapping

Suppose you have a lot of tasks, they are small and generally without priorities and binding to any groups. What to do with them? Break them up on Story Mapping. How it works:

Step 1. We build a sequence of how users will use your product and what steps they will take. A simple example:

Step 2. We write out on the stickers what details are available for each of these processes - the lower the sticker for each stage hangs, the lower its priority.

Result: the entire list of tasks is divided into steps of the user’s path, plus each feature has priorities (the lower the feature hangs in the sheet, the lower its priority in terms of the entire user path).

Where and how to apply

Let's say you really got a lot of tasks. Then you write them all out on stickers and do Story Mapping. Better - in a team.

Another option - you have a brainstorm, you come up with what will be your product further and what features to take into work. The team has a lot of ideas, some kind of Wishlist marketing “poured” to you - you need to understand how to cluster it all. Story Mapping works especially well in this situation.

Disclaimer: this method is applicable precisely from the point of view of product management, when there are many tasks, it is not clear which of them are the first to be considered. It’s rude when we just think over the product itself and what functionality it will include. Then it is already cut into pieces from which you can create sprints, and gets into the work.

Pros of Story Mapping

The method allows you to build connections in the system, on the basis of which it is then easier to form sprints.
When there are many stakeholders and many people who have interests in the project, the method allows you to agree on real priorities - which is more important and what is less.

Value & Effort (or Lean Prioritization) for ideas

Another good method that allows you to build priorities on a scale is Value & Effort (or Lean Prioritization).

Step 1. First you take 2 scales:

— , « » . , — . , , , Value. , , .
,

, (estimate), . Story Point- ( ) -.

Step 2. You evaluate all features by these two parameters: by significance and labor input. There are external systems (like Hygger or Airfocus Priorities & Roadmaps ) that allow you to automatically scatter your features in some way on such a board. The axes in this case do not come from zero - they adapt to the statistics that you have obtained.

What features to take in the first place? The most significant and lightest, which are closest to the axes - they are both in importance in the top and in value adequate:

If in the first place we take away cheap and good, then later - expensive, but cool:

Following are all the others. Features that are too expensive and have no meaning, you either leave "for later" or throw away.

Where and how to apply.

With custom development, such a thing makes sense to do with the client if:

he himself got confused
it generates strange ideas and requirements,
he has a certain budget constraint, and he does not understand how best to distribute it.

The latter situation is frequent. We are always limited by either budgets or resources, and we need to understand on the basis of what to distribute them. Moreover, managing projects, we can only manage the attention of our team and
our customer - nothing more, in fact. This method allows you to concentrate on the most important and the cheapest or on the expensive, but very important, and helps to choose what exactly to bet on at the moment.

This technique does not make you blindly believe the algorithm and take precisely the tasks recommended by it, but thanks to it you will at least have a hint in which direction to move. If you add new tasks to the system, it can be rebuilt. After all, it happens that you are very unsure of your estimates, and over time, analysts refine them, or you yourself refine the estimates of the complexity of programmers - in this case, the system can also be rebuilt in dynamics. Due to this, you will have a more adequate picture of the world.

MoSCoW

Another way to categorize features into multiple groups is the MoSCoW method. Inside there are very simple parameters:

M - Must Have : functionality that you can’t do without at all. Without it, you will not be able to release, your product will not work and will not be needed at all.

S - Should Have : the functionality that should be in the project, but other things being equal, you can somehow do without it.

C - Could Have : functionality desired for release.

W - Would Have : the least practical functionality - so to say, “everything else”.

, . Must Have , , , . Should Have — , , . Could Have — . , Must Have MVP.

It often happens that priorities are lowered from above, from the business, and they are concentrated on some “Wishlist” from Should Have, Could Have, Would Have, scoring on key things (Must Have). Usually we observe this, for example, in the development of the design of an online store or the design of some kind of project, where the rate is placed last but not least on the delivery payment system or something that actually generates a benefit to the business. Why? Because working with Must Have is painful and scary: you need to think about how it will be monetized, and nobody likes to get into it, although this is wrong.

Kano

Another way to categorize features that comes from marketing. The essence is simple: there are two axes: “user satisfaction” and “functionality”, and there is a division of the functional into groups. For each group of features, you need to understand how user satisfaction changes from adding this functionality.

The first group is the required functionality: the same Must Have from MoSCoW. If these features are - already good. There is no question of satisfaction: no one needs a product without them. Moreover, over time, the functions that were the highlight of the project at first become more and more mandatory. Example: for server software, kanban-board was once something of a sort, but now it is the same masthead.

Another group is one-dimensional functions. This means that there is a direct correlation between user satisfaction and the availability of this function. As soon as a function appears, satisfaction grows linearly. If you go back to the example of creating a car, it could be climate control there.

The third group is features that are attractive. This is what the user did not expect, but when he saw at least some implementation of this in your product, he went nuts and said “oh, cool!”. Those who flew by aeroflot probably saw how children were given “bribes” in order to emotionally attach them to the brand.

Gifts for children aboard Aeroflot are the source.

Once such a function appears even in mediocre implementation, satisfaction grows. And the steeper the implementation, the higher the satisfaction schedule.

Another group is unimportant functions. You can do them, you can not do them - everyone will be indifferent.

The last group is undesirable features. When they are gone - everything is fine, as soon as they appear - everything becomes bad. Such antifichi :)

This method is somewhat doubtful, since it is not clear how the priorities are selected for features. In theory, you need to interview users: as they think, this feature is good or not, and then cluster based on the opinions of users. At the same time, the users themselves must also be divided into target groups and watch how each function belongs to which target group.

People during polls often talk nonsense and simply lie. They may say that this is a very important feature, but in fact they will never pay money for it. Moreover, if you interview users, product feedback can be very toxic.

Example

You are planning on making the next releases and are interviewing a group of people. Some of them may say: “But you did a paid function there, because of it the product has become worse, fii!” Just because it is for money, this function will seem unnecessary to someone. Although for business, this may be the key thing that makes a profit.

Therefore, the Kano method is absolutely out of marketing, but as a long-term strategy there is a place to be.

The classic method of prioritizing bug lists

At the heart of it is a list of priorities from 0 to 8:

0 - Critical bugs
When the tester popped up and can no longer check when the system crashes or something breaks - in general, when it is impossible further.

1 - Critical usability and forgotten features
Here we apply, including the method of painting backlog, technical specifications, or a prototype (depending on what we have on hand) to determine if we have missed something.

2 - Non - critical bugs
There are bugs , but they do not interfere with testing the product further, or they allow you to go completely along the chain of either the order, or something else - that is, they allow us to fully check our product.

3 - Uncritical usability

4 - Texts

8 -Wishlist / we will not do it / at the discretion of the manager

Yes, the interval between 4 and 8 was made intentionally - the manager, if necessary, can prove any other tasks there.

For bug lists, the method is good, but it has a problem. By and large, we are optimizing the metric “ready - not ready” in the bug lists. The scope of work is clear. But it is often found that in non-critical usability they try to shove something that is on the verge of, it seems, usability and it seems to be nice to do it, but in fact it attracts some very serious feature.

Another problem is the subjectivity of the tester, which often has to be double-checked. Sometimes this is a rather time-consuming story when you personally look through all the bug lists: look at what he wrote there, and decide what to throw out and what to leave.

This method is not suitable for prioritizing backlogs - they need completely different criteria.

Assessment of tasks

Any prioritization should be based on the assessments given to us. After all, the complexity really affects the priority of a function. But how to determine the complexity and at what point is it worth discussing labor costs with a programmer? After all, before this, the manager still needs to set at least approximate estimates.

But seriously, there are usually three options.

- « » , , . , , - -, - -. :)

( ). - , - . , . , , ( - ).
: , , , .

: ( + ( * 3) + ) / 6.

, .

, , . , , , : , — . . — .

, , , . - , , , «» — . — 1 , , .

, « », . , .
Planning Poker

«» , - , , . .

Planning Poker — , . Story Mapping, ( , — ).

Planning Poker
1. , ;
2. , — ( , «»).

They help with prioritizing tasks in a backlog in conditions of uncertainty - when you only plan and evaluate the effect of introducing a particular function.

ICE Scoring

The abbreviation consists of three parameters:

Impact - the impact on the product, either from a business point of view, or how much money it will bring, or what this feature will give, how cool it is. The parameter is set in the range from 1 to 10.
Confidence - confidence in assessing complexity or in assessing the impact of features. For example, you came up with some kind of function and think that it will have a good effect on the project. There was no analytics, the data are inaccurate and so far the priority is based only on your personal opinion. The lower the confidence in your personal opinion, the lower the rate. It is also set in the range from 1 to 10.
Ease - labor costs or ease of implementation. It can also be set from 1 to 10. The simpler the function, the higher the score.

Impact

In order to evaluate the effect of a particular feature, it is worth considering several criteria:

it improves conversions,
she attracts new users
it keeps existing users
she adds value to the product.

If the function answers them, then it has a high impact on the product. For evaluation, you can take a scale from 1 to 10, you can take from 1 to 100. The latter is more convenient, since there is an take-off run.

Confidence

May be based on:

personal opinion, the opinion of the team, the opinion of external experts;
UX research;
polls
interview;
observations, including competitors;
MVP
A / B tests;
third-party research;
analytics;
top calls to technical support;
top requests from sales managers;
top customer requests.

It is better to use those where there are specific metrics and numbers, leave the opinion of people to “later”.

How to measure the level of confidence - the source

To obtain ICE, you need to multiply these three parameters - this will be the priority for implementation.

Pros : quick and easy.

Cons : the method has a rather limited scale - you can get many tasks of high priority, because the statements will be clear on them, the tasks themselves will be simple and will seem important.

RICE Scoring

4 parameters are used here:

Reach - coverage: how many users from this feature will get at least some satisfaction, either notice this feature or use it. Can be measured quantitatively: for example, 500 million users will experience this feature. It can be measured as a percentage - for example, 30% of users will use this feature.
Impact - influence: how much we really need this function, how much it will help us, how cool the function.
Confidence - confidence: similar to ICE Scoring, confidence in our estimates and forecast of influence.
Effort - laboriousness.

Functions that give great coverage, of which we are confident and which have a good effect on the product and at the same time cheap in terms of labor costs, are in the top by priority in the backlog.

Software for prioritization

There are several programs for automatic prioritization - for example, Hygger . This is a system for Product Owners, where there are many different models that allow you to "play around" with tasks.

What Hygger looks like from the inside - the source

The same thing to do in any Google Dock: just add three parameters, collect data - it will count. These will be your priorities. And then you yourself choose what to take in the sprint.

Sometimes managers use Jira to store all tickets and tasks. Unfortunately, it is not very convenient for prioritization - it is geared to the fact that someone prioritizes manually by simply dragging tickets up and down the backlog. It's cool if the backlog is not 1000 lines long, but at some point it will become tedious for you to do this with your hands.

Jira has certain ways to classify tasks into epics, components, releases, and you can mark tasks with some tags. There are several plugins for scoring ( Issue Score for Jira ,Priority Scoring Calculator ), but they are not very functional.

Of more or less adequate - external systems Hygger and Airfocus . They integrate with Jira, but they cost about the same as herself. Therefore, the easiest way is to integrate Google Dock and Jira: upload backlogs there synchronously and apply your formulas there as you need.

How to make friends Jira and Google Docs for prioritization

In addition to priorities, there is always a problem how to distribute the implementation of certain tasks in time. When there are only priorities, there is no guarantee that we will get a connected system (for example, you planned to make a basket, but it turned out that there was no catalog yet). Therefore, in addition to priorities, it is also worth using Gantt diagrams to see the connections in the system, how correctly it works by components and how optimally you distribute team resources over time.

In Jira, unfortunately, from the “box” this option is not very well implemented, so several plugins may also come in handy:

Portfolio (also expensive);
BigPicture (heavy);
MS Project ;
Merlin Project for MacOS.

As a result

We do not get rid of subjectivity - it remains at all levels. At the moment when we say “this is an important function” or “this is an unimportant function” and when we give some assessments, subjectivity is preserved. But thanks to the above methods, we can break this subjectivity into components: at least the picture will be clearer.

If you use such a parameter as “confidence in the assessment”, you can “twist” this confidence over time. For example, you have a good function that affects the product positively and cheaply, and coverage gives a lot, but confidence in it is low. Check it through metrics, analytics, a request from experts, questions to programmers - and specify.

Good for Planning Poker ratings, plus we looked at several methods for categorizing tasks. If you have a strategic session with a client, try Story Mapping with stickers and distributing them according to the user's steps. On internal products, the same method will help you choose the features that are worth taking in future releases. For backlogs, RICE Scoring is better than the rest to evaluate which tasks will go where.

But remember that the final decision is always up to the manager, and the numbers obtained using the methods only set the direction.

See you in the new videos on our YouTube channel !

Backlog scoring and prioritization techniques