Home Manage Development Prioritization in Scrum by ICE.Avito Experience

Prioritization in Scrum by ICE.Avito Experience

by admin

Hi, my name is Ilya, at Avito I’m a developer and part-time scrum master on a B2B team that does Autotech.

Today I’d like to talk about how my team and I started the process of prioritizing tasks and shaping their evaluation and re-evaluation processes. What difficulties we had to face and what profits we managed to acquire. I hope this article will be useful to those teams whose backlog contains > 50 items, but only the product owner has knowledge of what to do.

Introduction to Scrum

A little introduction to scrum, for those who have never encountered it before. If you already have an idea of the methodology and its artifacts, you can safely go to to the next section

Scrum translates from English as "scrum, " which is the name of one of the elements of rugby. The purpose of a scrum is to resume play after a minor infraction or stoppage. These processes are embedded in the methodology of teamwork Scrum. A scrum team must continually improve, achieve its goals, analyze its experiences, and learn valuable lessons from those experiences, whatever they may be. To facilitate this, the methodology involves a number of tools and meetings.

The scrum workflow is divided into iterations called sprints. Each sprint lasts from 1 to 4 weeks. In our case it is 2 weeks.

Before the start of the sprint, we gather for a planning session where we dial in our tasks. These are the tasks that must be completed in a future iteration. The main artifact of the sprint is the goal. The goal is what the whole team is focused on during the iteration. If the goal is not met, the sprint is considered a failure. In addition to the goal, the outcome of the planning is a set of tasks. This is called the sprint backlog.

In addition to planning, there are daily short meetings, daily, where the team discusses the process of moving toward the goal. Once per sprint there is a meeting called product backlog refinement (PBR) where we refine the upcoming tasks, assess their complexity, and decompose large tasks into those that can be done within the sprint.

There are also two activities every sprint : a sprint review and a sprint retrospective. These are meetings to get feedback from customers on the results of the sprint and to learn valuable lessons after the current iteration.

In this article, I describe the change in workflows between planning and PBR.

Prerequisites for using priorities

We are in the business of developing a B2B product, which involves heterogeneous tasks, lots of A/B testing and hypothesis testing, and our work is often like finding and creating innovative solutions. The team formed in the summer of 2020, its members were already working on scrum and had an understanding of processes like retrospectives, dailies, planning, and more. This allowed them to quickly begin communicating product value to users. Once the team was established the role of the product owner, hereafter I will call it PO, was the tech lead. Together we formed a product backlog, got to work, and all was well.

After a while, the product manager joined us, and the backlog began to grow rapidly. The backlog simultaneously contained hypotheses, MVP requests, and also had to keep in mind the development of things already in production and tech debt. And it wasn’t obvious for the development team which tasks would yield the best results.

There was also the problem that the backlog tail was rarely considered, meaning that we were overlooking important things. As a result, at another retrospective, we agreed to review prioritization techniques and try to use some framework to evaluate tasks. We hoped this would reduce the cognitive burden of constant prioritization on planning and product backlog refinement (PBR).

We wanted to understand :

How to prioritize and do so based on data from experiments and A/B tests.

How the PO shares his expertise in evaluating tasks. During a PO’s sabbatical, it would be great for the team to be able to prioritize on their own and take what’s important right now to work on.

How to handle ficharequests immediately and prevent them from dying in endless Slack chats.

  • What assessment methodologies and tools will help keep the backlog up to date.

  • After the retro, the target picture became clear:

    • The team has a methodology for evaluating tasks.

    • The backlog is always up to date and sorted by priority.

    • The command, when necessary, can give a priority rating to a new task without a PO.

    • New tasks are not lost in the bowels of the backlog, and they are prioritized in team-wide events.

    ICE, RICE or WHY’s?

    The number of prioritization systems is huge, and it was not clear to us which one to use. In our study, we considered both value-based prioritization and multicomponent assessments like WSJF or RICE.

    Nevertheless, a choice had to be made. We determined that :

    • Since the team is fairly young, we should use a slightly more subjective evaluation than if we had a lot of legacy and tweaking of one metric or another.

    • CustDev had not yet been put on stream, so it was quite difficult to estimate the reach of the audience that this or that feature influenced. Therefore, when choosing the prioritization systems, we excluded those that took this factor into account.

    • We have a large number of hypotheses that we want to test. We needed an evaluation tool that would allow us to take this into account.

    Based on these criteria, we realized that ICE framework is a good candidate. About it there is nice article on the Habra Here is the formula for estimating the framework problem :

    Prioritization in Scrum by ICE.Avito Experience

    We also created a rule in Jira that a green task with the "green" tag is tinted in this list. Now working with backlog prioritization is really handy.

    To summarize

    Let’s go over again the points of what we wanted in the target picture, and what we ended up with.

    Wanted :

    1. The team has a methodology for evaluating tasks.

    2. The backlog is always up to date and sorted by priority.

    3. The command, when necessary, can give a priority rating to a new task without a PO.

    4. New tasks are not lost in the bowels of the backlog, and they are prioritized in team-wide events.

    5. Ficrequests are not lost in the bowels of Slack and other means of feedback.

    Received :

    1. After a year, we can say that the ICE methodology fits us perfectly. But we still have quite a large number of hypotheses. The choice of evaluation methodology for a particular team should be approached based on what that team does. One of the main elements of evaluation in ICE is Confidence, if confidence is low we may as well either abandon the task or do an A/B test to increase confidence.

    2. The backlog is always up to date. Every sprint we go through it, updating the priorities. By looking at the backlog in Jira, you can see our tricks for the next 2-3 sprints.

    3. We can give an estimate of the task without a PO, but here we need to understand that the estimate will be more accurate the earlier we get involved in the process of working on it. I would like to note here separately that the inclusion of this item in the target picture had an interesting side effect. Almost every sprint, we began to take the tasks within the team-i.e., we begin to work not with the specific requirements of the task, but with a hypothesis of how it might affect the product. We run tests, do A/B, etc.

    4. New tasks are now rarely lost. We have created a separate filter for new tasks and tasks without priority, and on PSBR we go by this list.

    5. Ficharequests get lost a lot less often after we’ve made an agreement that we’ll start them in Jira or bring them to the daley as soon as we see them. We then evaluate each retest and either put it in the backlog or throw it away.

    6. We’ve learned how to work more efficiently in Jira, and now when you look at the backlog you don’t get the question "what’s next?" The PO can safely go on vacation without thinking that development will be concentrated in his absence on clearing up tech debt.

    7. The green goals allowed us to keep the team’s motivation high at all times.

    That’s all for now. Ask any questions in the comments.

    You may also like