Hi! I’ve been working in IT development in different IT companies, teams, and roles for almost 20 years. I’ve been using different methodologies. In this post, I’d like to share the lessons learned from working in SCRUM teams over the past 5-7 years and my views on setting tasks for development teams.

I’m going to share our SCRUM experience in organising and conducting Product Backlog Refinement sessions.

The entire process described in the SCRUM guide is summarised in a single paragraph:

Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. This is an ongoing activity to add details such as a description, order, and size. Attributes often vary with the domain of work.

Definition of Ready (DoR)

Since the process of detailing Product Backlog items is organised by the team and the Product Owner, they will collaborate to determine the need and the degree of detailing. Often, the criteria of a ready backlog item to be completed by a team within a sprint take the form of a check-list called Definition of Ready.

There is not much information about Definition of Ready (DoR) in the Russian segment of the Internet, and it deserves its own post. What’s important is that the criteria/check-list can be developed and supplemented by the team as processes progress, for example using decisions made at retro meetings. You can start small: with something real, rather than some far and ideal future. It is better to document even the first small list of criteria discussed by a team. This way all participants will understand each item on the list unambiguously and can go back to this list at any time.

The acceptance criteria is an important thing that should be included on the list from the very first versions. This is a list of checks/steps clear to everyone in the team (including professional testers) that have to be performed to verify that the backlog item has been implemented and that the implementation meets the requirements/expectations of the Product Owner.

Let’s look at the DoR first version, which we used when we started working as a team:

The task is written down: in Jira and/or linked to an article in Confluence.
The task has a value defined for a product/process user or a development team.
The task is clear to all team members.
The task has acceptance criteria defined.
The task has interface templates (if required).
The task can be performed within one sprint.
The task dependencies (if any) are indicated.

The Product Owner is a key participant of the PBR process

So we have agreed on the criteria to be met in the backlog item refinement process. Now back to our goal—how do we refine backlog items? The key player in this process is the Product Owner. If the Product Owner does not invest in refining backlog items, the team will not work effectively to create an increment. The entire team assists the Product Owner in the PBR process. Well, this is the ideal, but in fact only the most active participants do this.

First, the Product Owner, independently or with the help of analysts, defines and fixes the task in the backlog, in a written form in Jira and in articles in Confluence. This process is not yet strictly formalised and depends on the current workload and personal accountability of the Product Owner. But we regulated and scheduled our weekly Product Backlog Refinement meetings held by the Product Owner. The Product Owner shows the team the tasks that have to be taken to the next sprint and discusses them with the team. Such practice disciplines both the Product Owner and the team.

Since the process of holding a meeting is not yet strictly formalised, there is no strict pattern according to which the Product Owner holds a meeting. Look at the graphical representation of one of the refinement meeting flowcharts I found on scrum.org in the post titled Product Backlog Refinement explained (3/3).

Our practices

Before PBR meetings, the Product Owner can gather some team members to define and break down large and complicated tasks in advance. As in most cases, our SCRUM team is not perfect where everyone can do everything and knows everything. So we try to break down such tasks in advance and discuss them with team members who have different IT specialisations. All IT roles take part in the discussion: analyst, backend developer, frontend developer, designer, and tester. Additionally, we invite an architect to discuss bigger tasks that require changes in the architecture of the system.

Participation of representatives of all IT specialisations is necessary in order to look at the task from the perspective of each future participant, to ensure the most complete breakdown of the task into smaller tasks and prevent any significant controversial issues. This way you will not need any extra time in the sprint, or any research to solve a sudden problem you encountered in the process of the task implementation.

In the refinement process, we try to:

Form a set of detailed subtasks (each performer will have their own subtask or a set of subtasks),
Take dependencies into account,
Add or specify any original definitions of requirements in Jira and Confluence,
Agree upon and prepare changes for templates,
Design and describe the required API endpoints for frontend and backend developers,
Describe changes in services databases,
Discuss how we shall accept the task, what test data we shall use,
Decide which of the tests should be automated right away,
Define the acceptance criteria.

If we do not have enough time at this meeting to document all refinements in subtasks in a written form, we will continue to supplement descriptions based on our IT specialisation. We strive to supplement subtasks for PBR as much as possible. The better we do our work at this stage, the easier it will be for us and our colleagues to correctly estimate and implement the task in the sprint.

For example, if you agree in advance on the required API endpoints for a frontend or backend developer, later they will be able to work on the task within the sprint independently of each other, and the tester may start working on the autotest.

Such meetings help us not distract the entire team from working on the tasks within the current sprint. We bring the task decomposed earlier for general discussion. That way, we reduce staff time for a PBR meeting in which the entire team takes part. This will also help reduce the meeting time for sprint planning because by the time of planning, everyone in the team knows all the main tasks that we would like to take in the next sprint, and can look at their subtasks in greater detail later at a convenient time. At the time of planning, all we have to do is to update priorities and estimates of subtasks, and to understand how much we can really do in the next sprint.

Conclusions

When discussing our changes at retro meetings, many team members said that these PBR meetings:

Reduce the number of calls/meetings to refine tasks taken in the sprint,
Increase assurance of team members that the tasks taken will actually be completed within that sprint,
Accelerate testing processes,
Increase involvement in the project,
Give an understanding of further product development.

Returning to the question in the title of this post, we as a team believe that a regular PBR process is our investment in the ongoing product development. Hours spent on planning and design save days for development and testing in the future. And, of course, we still have room to grow in optimising our workflows, so it would be great if you share your experiences and best practices in the comments.

Below are some links to useful articles on this topic:

An article about benefits of Product Backlog Refinement: The Art of Product Backlog Refinement

One of the ways to formalise Product Backlog Refinement, 3 parts:

Product Backlog Refinement: Expense or Investment?