In this article, Agile Coach from inDriver Ekaterina Kolesnikova will share the experience of conducting PBR without any boring theory about “correct” planning.

When I joined the team, I noticed problems in the Product Backlog Refinement process. I proposed a new scenario for this process and it worked. I’m sure many of the problems I encountered are familiar to you.

• Crushing expert opinion. One person spoke on PBR: Tech Lead, Senior, Product Owner or other leader. The rest of the team members remained in quiet agreement, did not express an opinion, were poorly involved and did not understand the task.
• We’ll sort it later. Tasks were only specified after the start of the sprint.
• Tasks in Jira without a description. There was no documentation or parsing.
• No assessment. The sprint planning was chaotic, and the results were difficult to predict.
• No product or technical decomposition. They didn’t know what they were doing.

The scenario that I propose is suitable for a product team of eight people. The PBR process itself was divided into four stages:

Stage 0. Get it all done in advance

At least three days, and preferably a week before the PBR, the Product Owner sends information about the features that we would like to start work on. The development team looks over the information, prepares questions and offers solutions in advance. This greatly reduces the meeting time.

At this stage, it becomes clear which tasks are simple, and which will definitely take a lot of time to work out. This helps to better plan the timing of the upcoming PBR. To save time, simple tasks can be graded asynchronously and compared at the meeting. If the team is not new colleagues may come to the same conclusion, and the discussion of such problems takes a maximum of 10 minutes.

Artifacts and feature documentation include:

• The user problem we are solving.
• A hypothesis to solve this problem.
• Results of the research or experiment that support this hypothesis.
• The target audience of the feature.
• Product metrics we want to influence.
• Layouts.
• User Story Mapping (USM), Customer Journey Map (СJM).
• Keys for conversions (if necessary).
• Analytics events to add.
• Product decomposition and task description.

It is good practice to have detailed items in the product backlog at least two sprints ahead. This simplifies sprint planning as the Product Owner and Scrum team start planning with a clear, well-analyzed, and accurately evaluated set of user stories.

If the task falls into the sprint without a PBR, the sprint planning stretches in time, raises many questions, requires clarifications and/or leads to inconsistencies.

Stage 1. Product challenge

The Discovery Team, in our case, this is the Product Owner, Analyst, Designer, Technical Leader and business representatives, once again personally tell us about the stories that we would like to start work on.

The product challenge should take no more than 30 minutes. We discuss features from the point of view of the product (“what are we doing?”, “why are we doing it?”).

People ask pre-prepared questions. During the discussion, we write out new problems, risks and barriers to the implementation of the feature that cannot be solved quickly. When the product challenge ends, the Development Team looks at all of this and makes a decision:

1. To postpone further work until the Discovery Team resolves the issues that have arisen. In this case, we assign a new product challenge.

2. To continue the PBR process if the outstanding issues are not critical. In this case, the DevTeam may:

3. Drill down a feature discussion with the whole team (not the best way in terms of interaction efficiency).

4. Select a working group (a cross-functional team whose competencies allow it to fully work out the technical implementation of the feature).
5. Select several working groups (feature teams) so that each team tackles several decomposed user stories from one big feature. After the work is completed, the feature teams present the selected solutions to each other.

In my opinion, the last option is ideal for a team of eight or more people. We broke up so that each feature team had one representative from the platform. This helped to involve all participants and speed up the development of features.

Depending on the chosen work format and the complexity of the discussed feature, the DevTeam may:

• Start a technical elaboration within the current meeting (no more than 50 minutes).
• Agree on follow-up work (a new meeting or asynchronous mode of work via instant messenger — the team chooses any format that suits them).

The visually described Product Challenge process looks like this:

Stage 2. Technical challenge

DevTeam works on decomposed features in one of these formats: the whole team, a working group, or several feature teams. One important condition: in any format, the technical team is cross-functional, autonomous and empowered to make decisions on its own. Product Lead, TechLead, Product Designer and Scrum Master can participate in the technical challenge as external experts at the request of the team.

A checklist of questions that will help the team with the analysis of the problem on PBR:

1. How many modules are affected by the task?
2. How many external interactions and dependencies are there: contract formed with backend, work with other teams, top-level architecture worked out.
3. How many internal interactions are there?
4. Technical decomposition.
5. Estimated story points (complexity, volume, risks), did testing take these into account? Do you have time for conversions?
6. Risks. What can go wrong? What is the worst case scenario?
7. Acceptance Criteria (AC).
8. Definition of Ready (DoR) control.

You can also use the DoR checklist for all product teams:

1. Is there a description or presentation for the task?
2. Are there Acceptance Criteria (AC)?
3. Is there a Story Point (SP) estimate?
4. Are there User Interface (UI) layouts?
5. Are there analytical metrics?
6. Are there localization keys if needed?

The technical challenge lasts 50 minutes if the team continues the Product Challenge meeting, or around an hour and a half if it is a separate meeting. The duration also depends on the complexity of the feature.

If the feature team can’t “buff” the feature in less than an hour and a half, it means that the feature was badly decomposed. This is worth discussing in retrospect.​​

Stage 3: Final challenge

This is a general event lasting no more than 30 minutes, in which feature teams present each to other (if they have been separated), the product lead, the technical lead and the designer, the technical solution of the feature.

The purpose of this stage is to get approval from the above participants on the further implementation of the feature within the next sprints, and also to sync up if several teams have been working on the features.

During the discussion, the team checks each feature according to DoR and parks the questions that have arisen during the meeting on a separate board. At the end, we make a decision: the feature is ready for the sprint (converted into Ready for development) or additional clarifications/discussions are needed. Also one responsible person is selected who will transfer all information from Miro to Jira.

What the participants say

I spoke with the participants in our PBR experiment. Here is some feedback from my team members:

Backend developer

Before, the analysis of what the business wants did not allow for discussion of any points. And this entailed task changes on the fly. When we started discussing a task at PBR, because the team was so large, it turned into a story that wasted quite a lot of time and lowered the quality of internal communication. Now, when we divide the meeting into relatively small teams, everything works fairly well, but there are always moments that we want to improve.

QA engineer

Pros:

• Understanding the essence of the tasks before development.
• Documentation testing has become the responsibility of the team, not the testers.
• The priority of the tasks became apparent.
• Everyone could express their “essence [’fe’ in Armenian’]”.

Cons:

• Takes time.
• Forced to think.

Android developer

Before the arrival of Agile Coach, we had no idea what story points were and that tasks should be evaluated! Because of this we had sprints for 1–2 months without results. There were no discussions, it was more like “there are problems here, okay let’s take a look”. Thanks to the facilitator’s brain cells, a meeting structure has appeared. We now understand that we can assess everything, and then plan a sprint.

Product Owner

• There was unpredictable development, there was no understanding of the timing for the development of several tasks — fixed, except for a few exceptions.
• Missing the development timeline — fixed, I think we hit 80%.
• Only a few people participated in the discussion — fixed.
• There was no common understanding of task assessment — plus or minus, you need to keep recalibrating
• There was no preparation for the PBR and no involvement in the discussion. The team did not take responsibility for the task — now everyone is involved, but sometimes they perform more formally.
• The task processing quality has improved.