And using linear programming methods
Have you encountered the concept of linear programming? And its application in practice? At the university we study different sections of mathematics, we are told about mathematical models and methods, but the issue of their practical application is often given insufficient attention.
In this article I will share off page seo service the main points of my report presented at the Analyst Days 6 conference. In it I tried to show how linear programming methods can be applied in the work of a team living in sprints. Under the cut you will find an alternative view on sprint planning.
Sprint Planning and Issues
I came to Alfa-Bank in 2017 and started as a systems analyst in the product team: my colleagues and I were developing an online bank for legal entities and used Scrum in our work.
At first, we tried to fully comply with this framework - to perform all the necessary rituals. However, gradually we realized that following them all is expensive, it eats up time that could be devoted to product development. We no longer have a sprint review, and retrospectives are now held when necessary. But what remains unchanged is planning.
During the planning process, we had a product backlog at the input and a sprint backlog at the output. Naturally, the planning did not go smoothly. And now I will tell you why.
There is such a thing as capacity.

It shows the weight of work that a team (or its member), on average, closes during a sprint in story points (hereinafter referred to as sp).
Usually, for us it was on average 20 sp. Accordingly, during planning, we started to collect tasks from the product backlog until their total weight did not exceed the team capacity.
In practice, there were situations when we would get 20 sp and start a sprint, and just a couple of days later some of the team members would have already closed all their tasks. Well, that's it - there's no more work, you can rest. Or not?
How did you act in such situations?
In the sprint, additional elements were taken from the product backlog, for which no one had committed during planning and, therefore, no one had promised to close them during the sprint.
We were engaged in development tasks, which, of course, is good, but was not always valuable for the product.