Using Kanban to Prepare Scrum Backlog
I propose the transfer of a small article by Anders Abel to a topic of concern to me at the moment - a qualitative and formalized process of preparing tasks for transfer to development, provided that the development is carried out on a screen. If someone has experience using the approach described by this author, it would be interesting if you shared the nuances. Original article: “Using Kanban for Scrum Backlog Grooming” .
Picture on request grooming:
')
***
Backing up scam projects is an important task. It very quickly grows to hundreds of tasks that are at different stages of readiness for inclusion in the sprint. In my current project, we connected a Kanban board to help support backlog and improve the efficiency of grooming.
It seems to me that in many respects the backlog of the product and the role of the product owner are the bottlenecks of the scram. Scrum streamlines the development process and requires the provision of clear requirements for its launch. It helps to see what we, the developers, already know: if the project fails, then it is not always our fault, because we cannot do our work well with bad demands. So now, when the problem with requirements is noticeable and understandable, it's time to take on the process of processing requirements.
In my current project there are several different stages through which each element of the product backlog passes:
1. New task gets into grocery backlog.
2. The product owner determines whether this task is useful and, depending on this, either deletes it immediately or initiates a more detailed analysis.
3. The product owner (or the analyst helping him) performs the analysis.
4. The resulting elements of the product backlog are presented to the development team during the backing grooming meeting.
To accompany the above process, we use a kanban board.
Kanban board
Our Kanban board contains four columns that visualize the phasing described above:
1. New tasks
2. Analytics
3. Requirements are ready
4. Backlog (or Requirements agreed)
When adding a backlog for the first time, the item is placed in the column of new tasks. The product owner determines if it makes sense to spend resources on researching this task. If so, it moves to the analytics column. This is a sort of In Progress status for the product owner and analyst. When they think they’re done with the analysis, they move the item to the “Requirements Ready” column. When this column accumulates 10–20 items (we don’t have a hard limit), it’s time to meet for the grooming backlog, during which the developers disassemble the items from the last column. If they believe that the tasks are clear enough to continue working with them, they move them to the “Backlog” status, while at the same time providing an estimate of the dates (we are evaluated in hours, and not in story points).
If the developers believe that something is missing in the description of the backlog element, they send the element back to analytics status, putting a list of questions to be answered.
Sprint planning
When the time comes for a meeting to plan a new sprint, only those items that are in the “Backlog” status are considered. We work in Jira and filter out the scram-board in such a way that tasks with a status other than the “Backlog” status are not displayed at all.
As a result, a minimum amount of time is spent on planning the sprint to discuss the essence of the backlog elements, as this has already been discussed during grooming. The focus on planning is shifted to approval by the product owner of the list of prioritized items and the movement of these items to the sprint. By this time, the product owner already has an estimate of the implementation dates, so, having information about the cost of implementation and the business value of these tasks (and the product owner must understand the business value), it becomes possible to make an informed decision about whether the task should be solved now, postponed to a later sprint, or perhaps it should not be implemented at all.
Beklog processing control
For an effective team of scram practitioners, the development team is more important than ever to be sure that the backlog is filled with the data the team needs in order to remain effective. It is quite difficult to manage backlog without proper instrumental support or without understanding how to bring its elements into a properly detailed state. We can say that this is impossible for most projects, except for the smallest.
If we spend so much time improving the development process, it seems to me that it would be natural to improve the pre-development process as well. I also think that the presence of a clearly defined process of preparing elements for placement in a grocery backlog is, unfortunately, a rather rare case. In my experience, this work is usually performed irregularly and without any plan, which seems to me to be the wrong approach.
I am going to continue working with my Kanban board to be sure that managing the product backlog does not slip into a random process. After several months of use, it is obvious that an established process of managing the product backlog with good instrumental support really helps.
Picture on request grooming:
')
***
Backing up scam projects is an important task. It very quickly grows to hundreds of tasks that are at different stages of readiness for inclusion in the sprint. In my current project, we connected a Kanban board to help support backlog and improve the efficiency of grooming.
It seems to me that in many respects the backlog of the product and the role of the product owner are the bottlenecks of the scram. Scrum streamlines the development process and requires the provision of clear requirements for its launch. It helps to see what we, the developers, already know: if the project fails, then it is not always our fault, because we cannot do our work well with bad demands. So now, when the problem with requirements is noticeable and understandable, it's time to take on the process of processing requirements.
In my current project there are several different stages through which each element of the product backlog passes:
1. New task gets into grocery backlog.
2. The product owner determines whether this task is useful and, depending on this, either deletes it immediately or initiates a more detailed analysis.
3. The product owner (or the analyst helping him) performs the analysis.
4. The resulting elements of the product backlog are presented to the development team during the backing grooming meeting.
- Developers have questions and they wrap the item back for additional detail.
- Developers agree on an item and rate it.
To accompany the above process, we use a kanban board.
Kanban board
Our Kanban board contains four columns that visualize the phasing described above:
1. New tasks
2. Analytics
3. Requirements are ready
4. Backlog (or Requirements agreed)
When adding a backlog for the first time, the item is placed in the column of new tasks. The product owner determines if it makes sense to spend resources on researching this task. If so, it moves to the analytics column. This is a sort of In Progress status for the product owner and analyst. When they think they’re done with the analysis, they move the item to the “Requirements Ready” column. When this column accumulates 10–20 items (we don’t have a hard limit), it’s time to meet for the grooming backlog, during which the developers disassemble the items from the last column. If they believe that the tasks are clear enough to continue working with them, they move them to the “Backlog” status, while at the same time providing an estimate of the dates (we are evaluated in hours, and not in story points).
If the developers believe that something is missing in the description of the backlog element, they send the element back to analytics status, putting a list of questions to be answered.
Sprint planning
When the time comes for a meeting to plan a new sprint, only those items that are in the “Backlog” status are considered. We work in Jira and filter out the scram-board in such a way that tasks with a status other than the “Backlog” status are not displayed at all.
As a result, a minimum amount of time is spent on planning the sprint to discuss the essence of the backlog elements, as this has already been discussed during grooming. The focus on planning is shifted to approval by the product owner of the list of prioritized items and the movement of these items to the sprint. By this time, the product owner already has an estimate of the implementation dates, so, having information about the cost of implementation and the business value of these tasks (and the product owner must understand the business value), it becomes possible to make an informed decision about whether the task should be solved now, postponed to a later sprint, or perhaps it should not be implemented at all.
Beklog processing control
For an effective team of scram practitioners, the development team is more important than ever to be sure that the backlog is filled with the data the team needs in order to remain effective. It is quite difficult to manage backlog without proper instrumental support or without understanding how to bring its elements into a properly detailed state. We can say that this is impossible for most projects, except for the smallest.
If we spend so much time improving the development process, it seems to me that it would be natural to improve the pre-development process as well. I also think that the presence of a clearly defined process of preparing elements for placement in a grocery backlog is, unfortunately, a rather rare case. In my experience, this work is usually performed irregularly and without any plan, which seems to me to be the wrong approach.
I am going to continue working with my Kanban board to be sure that managing the product backlog does not slip into a random process. After several months of use, it is obvious that an established process of managing the product backlog with good instrumental support really helps.
Source: https://habr.com/ru/post/275511/
All Articles