Work with task backlog from the point of view of a project manager in Retail Rocket
Habr, hello! We continue to share with the community the internal kitchen Retail Rocket , and today we will tell about our approach to working with backlog. Proper prioritization of tasks is the first step in solving such important project problems as:
Over the years of the project’s existence, we have developed a system in which all work with the task list follows two principles: “don’t start a new one if you don’t finish the old one” and “always clear a place for a new functional”.
This is how these two principles are embodied in the rules of backlog prioritization.
')
If you are sure that you have found a bug, you should fix it first of all, before developing any new functionality. It is necessary to follow this rule for the following reasons:
It is important to emphasize that this is not about expanding the functionality, but about modifications, some inaccuracies (they can be quite substantial). If suddenly after the release of the functional in the battle it turned out that some details were not taken into account at the design stage, these improvements should go on priority immediately after the bugs. The reason why this type of tasks goes ahead of the others is the same as in working with bugs - this is the previously started, but not completed functionality, which means that you need to finish all the modifications before taking on something new.
I have not yet met companies for my practice (and this is more than 10 companies in which I worked myself, and about the same with which I am well acquainted from the inside), except for ours, which would have tasks to remove functionality in backlog, although, probably, such exist. Each new feature increases the cost of producing the next feature, in other words, to make the 10th feature in the project much easier than the 5000th feature. This is due to the fact that when developing the latter, it is necessary to figure out how it fits into all 4999 previously made features.
Also, a large number of features reduces the project's build speed and the speed of passing tests, which, in aggregate, greatly complicates the work on 5000th features, which means that reducing the number of features in a project has a positive effect on the production speed of new ones.
We have developed the following formula for ourselves: for every 3 man-days of developing new functionality, 2 man-days are taken into work to eliminate technical debt and 2 man-days to improve the system as a whole (intangible tasks). The coefficients (2 or 3 man-days) can be argued, and they, of course, can and should change depending on the stages of the project’s life. But the idea that for every man-day spent on the new functionality, we must fulfill both the technical duty tasks and the tasks of improving the system as a whole, is pretty obvious.
In conclusion, we can say that real work is, of course, more complicated than the rules invented and sometimes we have to break them or move away from them, but in everyday work the very existence of the rules greatly simplifies life.
Write in the comments your thoughts on how you work in backlog and share links to materials that you liked.
Andrey Chizh,
CTO Retail Rocket
PS
We always welcome new team members and we have several vacancies at once to the “.NET Developer” position . Our technological stack and level of tasks can be estimated in the very first post on Habré . You can send your resume directly to me at avchizh@retailrocket.ru (we have no HR, we will communicate directly at once).
- reduction of technical debt,
- support of production speed,
- product quality support.
Over the years of the project’s existence, we have developed a system in which all work with the task list follows two principles: “don’t start a new one if you don’t finish the old one” and “always clear a place for a new functional”.
This is how these two principles are embodied in the rules of backlog prioritization.
')
The first priority is always given to working with bugs.
If you are sure that you have found a bug, you should fix it first of all, before developing any new functionality. It is necessary to follow this rule for the following reasons:
- A bug is a previously developed functional, in which a mistake was made, and therefore, obeys the first principle “do not start a new one if you have not finished the old one”.
- Due to bugs in the system, it may be difficult to develop new system functions, since These functions have to be entered into the environment with bugs. This is not only difficult, but also demoralizing the team. Here the second principle comes into force: “always clear the place for a new functional”.
The second priority is all the improvements on the previously created functionality.
It is important to emphasize that this is not about expanding the functionality, but about modifications, some inaccuracies (they can be quite substantial). If suddenly after the release of the functional in the battle it turned out that some details were not taken into account at the design stage, these improvements should go on priority immediately after the bugs. The reason why this type of tasks goes ahead of the others is the same as in working with bugs - this is the previously started, but not completed functionality, which means that you need to finish all the modifications before taking on something new.
The third priority is the task of removing the old functionality or MVP-development, which were not needed
I have not yet met companies for my practice (and this is more than 10 companies in which I worked myself, and about the same with which I am well acquainted from the inside), except for ours, which would have tasks to remove functionality in backlog, although, probably, such exist. Each new feature increases the cost of producing the next feature, in other words, to make the 10th feature in the project much easier than the 5000th feature. This is due to the fact that when developing the latter, it is necessary to figure out how it fits into all 4999 previously made features.
Also, a large number of features reduces the project's build speed and the speed of passing tests, which, in aggregate, greatly complicates the work on 5000th features, which means that reducing the number of features in a project has a positive effect on the production speed of new ones.
And the last thing you need to do is to develop new functionality.
We have developed the following formula for ourselves: for every 3 man-days of developing new functionality, 2 man-days are taken into work to eliminate technical debt and 2 man-days to improve the system as a whole (intangible tasks). The coefficients (2 or 3 man-days) can be argued, and they, of course, can and should change depending on the stages of the project’s life. But the idea that for every man-day spent on the new functionality, we must fulfill both the technical duty tasks and the tasks of improving the system as a whole, is pretty obvious.
In conclusion, we can say that real work is, of course, more complicated than the rules invented and sometimes we have to break them or move away from them, but in everyday work the very existence of the rules greatly simplifies life.
Write in the comments your thoughts on how you work in backlog and share links to materials that you liked.
Andrey Chizh,
CTO Retail Rocket
PS
We always welcome new team members and we have several vacancies at once to the “.NET Developer” position . Our technological stack and level of tasks can be estimated in the very first post on Habré . You can send your resume directly to me at avchizh@retailrocket.ru (we have no HR, we will communicate directly at once).
Source: https://habr.com/ru/post/329346/
All Articles