The post has been translated automatically. Original language: Russian Russian
Hello everyone Today I'm sharing a real case about how one product team faced chronic problems in planning sprints and fulfilling commitments, and how we managed to fix it.
Problem #1: Burning tasks and blurred sprint boundaries
The first thing that caught my eye after several sprints of observation was the behavior of the product manager. He had a habit of regularly "throwing" new tasks into an already running sprint. The reasoning was standard: "There is a very, very urgent task from an important stakeholder*, it needs to be dragged into the sprint right now!"
- Example: The team has planned a sprint to develop a new feature A (score 13 Story Points) and fix bug B (5 Story Points). In the middle of the sprint, the product manager brings the task in ("Urgently correct the text on the main page, the CEO asked!", rating 3 Story Points). The team is forced to get distracted, the context is lost, and as a result, feature A is not completed, and task B is done in a hurry with possible errors. At the same time, the planned bug B remained untouched.
- Effects: This led to a constant delay in deadlines for scheduled tasks, demotivation of the team (the feeling that their initial plan was worthless) and the inability to focus.
Problem #2: Underestimating real performance (Capacity)
The second point came to light when analyzing the performance chart in Jira. This report clearly shows how much work the team plans to take on (Capacity in Story Points, hours, or other units) and how much it actually performs.
We saw that the team consistently "performed" by about 100 Story Points per sprint. However, time after time, sprint after sprint, tasks for 200 or even 300 Story Points were taken into the sprint backlog. Reports on completed tasks eloquently showed that the team was physically unable to cope with such a volume. This situation lasted for at least six months.
- Example: During planning, the team estimates its available capacity at 120 Story Points. However, under pressure or excessive optimism, they gain 250 Story Points in the sprint tasks. By the end of the sprint, it turns out that only 95 Story Points of tasks have been completed. And so it goes from sprint to sprint.
- Consequences: Chronic non-fulfillment of obligations, burnout of employees, loss of trust on the part of stakeholders and a feeling of hopelessness ("we won't be able to do anything anyway").
Solution: Open dialogue and realistic planning
Both of these issues were openly raised and discussed at the RETROspective (By the way, I recommend that you familiarize yourself with the frameworks for conducting retrospectives, this is a powerful tool!).
The team made two key decisions:
- Sprint boundary protection: We agreed with the product manager that new tasks can be added to the active sprint only in an exceptional case (for example, a critical bug blocking the work of all users) and only after discussion with the team and removing an equivalent task pool from the current sprint. The main stream of new "urgent" tasks should go through the standard prioritization and planning process for the next sprint.
- An example of a dialogue with a product: "We understand the importance of this new task. However, the current sprint is already fully loaded. Let's see together which of the current tasks we can remove to make room for this one, or we can schedule it as the very first one in the next sprint, which starts in a week. How do you like this option?"
- Planning based on real Capacity: The team began to focus on actual data about its performance (the same ~100 Story Points) when planning a sprint. Instead of trying to "cram in the impossible," they began to take on the work that they could actually complete.
Results: Predictability and increased speed
The first changes became noticeable within a month: the team began to consistently "meet expectations", that is, to perform almost all the tasks planned for the sprint.
And the most interesting thing happened a block later.
Contrary to fears that the team would "relax" and do less, the opposite happened.: The team's speed has increased by almost one and a half times! Instead of the previous 100 Story Points, the team steadily began to close about 140-150 Story Points per sprint.
This case clearly demonstrates how just two seemingly simple process changes have led to significant improvements.
Why it is so important to work with the Capacity of the product team (and how it can be visualized):
Working with the Capacity of a team is not just about numbers in Jira, it's about creating a healthy, predictable, and efficient work environment.
- Predictability and trust: When a team regularly delivers on what it promises, it strengthens the trust of stakeholders. They can count on the team and make their own plans.
- Visualization: The graph "Planned Story Points vs. Completed Story Points" by sprints. Before the changes, there is a big gap between the numbers. After the changes, the lines almost match.
- Reducing stress and burnout: Constantly overloading and breaking deadlines is a direct path to burnout. Realistic planning allows the team to work at a steady pace.
- Visualization (indirectly): You can track the team's "happiness index" or the number of sick days. Although there are no direct graphs of performance, an improvement in Capacity often correlates with an improvement in these indicators.
- Quality improvement: When there is no rush and constant context switching, the team has time to do their job efficiently, think over solutions and test them.
- Visualization: Graph of "Number of bugs found after release" by sprints or releases. Expected decrease after stabilization of work with Capacity.
- Improving focus and reducing context switching costs: Juggling multiple tasks, especially when new "urgent" ones are constantly flying into the sprint, is a huge loss of efficiency. Each switch takes time and mental effort.
- Visualization (conceptual): You can show a diagram where each "flying in" task breaks the flow of work on the main task, adding "switching time" before and after. Or the graph "Number of unplanned tasks in a sprint" – its decrease will be an indicator of improvement.
- Real Productivity Growth (Velocity): As the case showed, when a team works with focus, without overloading and with clear priorities, its natural speed increases over time. People interact better, processes are debugged.
- Visualization: A graph of the "Velocity of the team (Completed Story Points)" by sprints. In this case, it would show stagnation or a floating result at ~100 SP, followed by an increase to ~150 SP.
Imagine a conveyor belt: if you constantly try to load more parts onto it than it can handle, or change the type of parts on the go, you'll get congestion, defective parts, and poor overall performance. But if you optimize the flow for the actual capacity of the pipeline, it will run smoothly and efficiently.
Key conclusions from this case:
- Transparency is the first step to a solution: Awareness and open discussion of problems (for example, in retrospect) are critically important.
- Sprint protection is not a whim, but a necessity: The team must be able to focus on coordinated tasks in order to achieve the sprint goal.
- Planning from real Capacity is the key to success: You should not deceive yourself and stakeholders by taking on a deliberately impossible amount of work. Data (for example, from Jira) is your best friend.
- Less chaos means more productivity: Eliminating constant distractions and overloads not only makes work more comfortable, but also paradoxically increases overall productivity.
- Trust and communication with the product manager: It is important to build partnerships where the product manager understands the limitations of the team and participates in realistic planning.
Всем привет! Сегодня делюсь реальным кейсом о том, как одна продуктовая команда столкнулась с хроническими проблемами в планировании спринтов и выполнении взятых обязательств, и как нам удалось это исправить.
Проблема №1: "Горящие" задачи и размытые границы спринта
Первое, что бросилось в глаза после нескольких спринтов наблюдения, – это поведение продакт-менеджера. У него была привычка регулярно "подбрасывать" в уже запущенный спринт новые задачи. Аргументация была стандартной: "Есть очень, очень срочная задача от важного стейкхолдера*, её надо затащить в спринт прямо сейчас!"
- Пример: Команда запланировала на спринт разработку новой фичи А (оценка 13 Story Points) и исправление бага Б (5 Story Points). В середине спринта продакт-менеджер приносит задачу В ("Срочно поправить текст на главной странице, попросил CEO!", оценка 3 Story Points). Команда вынуждена отвлечься, контекст теряется, и в итоге фича А не завершена, а задача В сделана в спешке с возможными ошибками. При этом запланированный баг Б так и остался нетронутым.
- Последствия: Это приводило к постоянному срыву сроков по запланированным задачам, демотивации команды (ощущение, что их первоначальный план ничего не стоит) и невозможности сфокусироваться.
Проблема №2: Недооценка реальной производительности (Capacity)
Второй момент выявился при анализе диаграммы производительности в Jira. Этот отчет наглядно показывает, сколько команда планирует взять работы (Capacity в Story Points, часах или других единицах) и сколько реально выполняет.
Мы увидели, что команда стабильно "перформила" примерно на 100 Story Points за спринт. Однако, раз за разом, спринт за спринтом, в бэклог спринта бралось задач на 200, а то и 300 Story Points. Отчеты по завершенным задачам красноречиво показывали, что команда физически не справляется с таким объемом. Эта ситуация продолжалась не менее полугода.
- Пример: На планировании команда оценивает свою доступную емкость в 120 Story Points. Однако, под давлением или излишним оптимизмом, они набирают в спринт задач на 250 Story Points. К концу спринта оказывается, что выполнено задач только на 95 Story Points. И так из спринта в спринт.
- Последствия: Хроническое невыполнение обязательств, выгорание сотрудников, падение доверия со стороны стейкхолдеров и ощущение безнадежности ("мы все равно ничего не успеем").
Решение: Открытый диалог и реалистичное планирование
Обе эти проблемы были открыто подняты и разобраны на РЕТРОспективе (Кстати, рекомендую ознакомиться с фреймворками проведения ретроспектив, это мощный инструмент!).
Команда приняла два ключевых решения:
- Защита границ спринта: Договорились с продакт-менеджером, что новые задачи могут быть добавлены в активный спринт только в исключительном случае (например, критический баг, блокирующий работу всех пользователей) и только после обсуждения с командой и изъятия равнозначного по объему пула задач из текущего спринта. Основной же поток новых "срочных" задач должен проходить через стандартный процесс приоритезации и планирования на следующий спринт.
- Пример диалога с продактом: "Мы понимаем важность этой новой задачи. Однако, текущий спринт уже полностью загружен. Давай вместе посмотрим, какую из текущих задач мы можем убрать, чтобы освободить место для этой, либо мы можем запланировать ее самой первой в следующий спринт, который начнется через неделю. Как тебе такой вариант?"
- Планирование на основе реальной Capacity: Команда начала ориентироваться на фактические данные о своей производительности (те самые ~100 Story Points) при планировании спринта. Вместо того чтобы пытаться "впихнуть невпихуемое", они стали брать в работу тот объем, который реально могли завершить.
Результаты: Предсказуемость и рост скорости
Первые изменения стали заметны уже через месяц: команда начала стабильно "попадать в ожидания", то есть выполнять практически все запланированные на спринт задачи.
А самое интересное произошло через квартал.
Вопреки опасениям, что команда "расслабится" и будет делать меньше, произошло обратное: скорость команды (Velocity) увеличилась почти в полтора раза! Вместо прежних 100 Story Points, команда стабильно начала закрывать около 140-150 Story Points за спринт.
Этот кейс наглядно демонстрирует, как всего два, казалось бы, простых изменения в процессах привели к значительным улучшениям.
Почему так важно работать с Capacity продуктовой команды (и как это можно визуализировать):
Работа с Capacity (мощностью, производительностью) команды – это не просто про цифры в Jira, это про создание здоровой, предсказуемой и эффективной рабочей среды.
- Предсказуемость и доверие: Когда команда регулярно выполняет то, что обещает, это укрепляет доверие стейкхолдеров. Они могут рассчитывать на команду и строить свои планы.
- Визуализация: График "Planned Story Points vs. Completed Story Points" по спринтам. До изменений – большой разрыв между числами. После изменений – линии практически совпадают.
- Снижение стресса и выгорания: Постоянная перегрузка и срыв дедлайнов – прямой путь к выгоранию. Реалистичное планирование позволяет команде работать в устойчивом темпе.
- Визуализация (косвенно): Можно отслеживать "индекс счастья" команды или количество больничных. Хотя прямых графиков производительности тут нет, улучшение Capacity часто коррелирует с улучшением этих показателей.
- Повышение качества: Когда нет спешки и постоянного переключения контекста, у команды есть время делать свою работу качественно, продумывать решения и тестировать их.
- Визуализация: График "Количество багов, найденных после релиза" по спринтам или релизам. Ожидаемое снижение после стабилизации работы с Capacity.
- Улучшение фокуса и снижение потерь на переключение контекста: "Жонглирование" множеством задач, особенно когда в спринт постоянно влетают новые "срочные", – это огромные потери эффективности. Каждое переключение требует времени и умственных усилий.
- Визуализация (концептуальная): Можно показать диаграмму, где каждая "влетевшая" задача разрывает поток работы над основной задачей, добавляя "время на переключение" до и после. Или график "Количество незапланированных задач в спринте" – его снижение будет показателем улучшения.
- Рост реальной производительности (Velocity): Как показал кейс, когда команда работает сфокусированно, без перегрузок и с четкими приоритетами, ее естественная скорость со временем растет. Люди лучше взаимодействуют, процессы отлаживаются.
- Визуализация: График "Velocity команды (Completed Story Points)" по спринтам. В данном кейсе он бы показал стагнацию или плавающий результат на уровне ~100 SP, а затем рост до ~150 SP.
Представьте себе конвейер: если вы постоянно пытаетесь закинуть на него больше деталей, чем он может обработать, или меняете тип деталей на ходу, вы получите заторы, брак и низкую общую производительность. Но если вы оптимизируете поток под реальную мощность конвейера, он будет работать плавно и эффективно.
Ключевые выводы из этого кейса:
- Прозрачность – первый шаг к решению: Осознание и открытое обсуждение проблем (например, на ретроспективе) критически важны.
- Защита спринта – не прихоть, а необходимость: Команда должна иметь возможность сфокусироваться на согласованных задачах для достижения цели спринта.
- Планирование от реальной Capacity – залог успеха: Не стоит обманывать себя и стейкхолдеров, беря на себя заведомо невыполнимый объем работы. Данные (например, из Jira) – ваш лучший друг.
- Меньше хаоса – больше продуктивности: Устранение постоянных отвлечений и перегрузок не только делает работу комфортнее, но и парадоксальным образом повышает итоговую производительность.
- Доверие и коммуникация с продакт-менеджером: Важно выстроить партнерские отношения, где продакт-менеджер понимает ограничения команды и участвует в реалистичном планировании.
More from this author
Share
