Релиз снова переносится, и стейкхолдеры обвиняют команду в медлительности. Вы пытаетесь объяснить, что за месяц в бэклог накинули двадцать новых «критичных» фич, но бизнес глух к оправданиям. Пора прекратить спорить и положить на стол Burnup Chart — единственный график, который математически доказывает, кто именно срывает дедлайны.
Оптическая иллюзия: Почему Burndown подставляет команду
Scrum Guide 2020 требует радикальной прозрачности артефактов. Когда вы используете стандартный Burndown Chart (график сгорания), вы видите только одну падающую линию оставшейся работы. Если менеджер втихую докинул задач в релиз, линия сгорания задирается вверх. Руководство смотрит на график и делает вывод: разработчики лентяи, работа стоит на месте.
Burnup Chart (график накопления) ломает эту оптическую иллюзию. Он разделяет данные на две независимые кривые. Нижняя линия показывает выполненную работу (Completed Work). Верхняя линия показывает общий объем работы (Total Scope).
Пересечение этих двух линий — это дата вашего релиза. Если нижняя линия стабильно ползет вверх, команда работает отлично. Если при этом верхняя линия улетает в космос, вы стали жертвой Scope Creep (раздувания требований). Финишная ленточка просто убегает от бегунов. График переводит проблему из плоскости «вы медленно кодите» в плоскость «вы не умеете управлять бэклогом».
Пытаться доползти до дедлайна с постоянно растущим бэклогом — это как пытаться доесть суп, в который повар прямо на ходу доливает кипяток. Вы можете работать ложкой со скоростью блендера, но тарелка всё равно переполнится, а вы просто обожжетесь. Зафиксируйте границы тарелки.
Таблица
| Сценарий | Обычный Burndown Chart | Burnup Chart |
|---|---|---|
| Бизнес добавил 20 Story Points в релиз | Линия оставшейся работы взлетает вверх. Команда выглядит неэффективной. | Верхняя линия (Scope) прыгает вверх. Видно, что объем работы изменился. |
| Команда работает с нормальной скоростью | Линия стоит на месте (плато), так как добавленные задачи компенсируют сделанные. | Нижняя линия (Completed) уверенно растет. Прогресс команды очевиден. |
| Прогнозирование даты релиза | Невозможно предсказать финиш, если скоуп постоянно меняется. | Продлеваем обе линии в будущее и видим точную точку их пересечения. |
План действий: Как остановить бег за горизонт
Выведите Burnup Chart на большой экран прямо на Sprint Review. Перестаньте оправдываться за сдвинутые сроки. Покажите стейкхолдерам две линии. Ткните пальцем в растущий скоуп и задайте прямой вопрос: «Команда сожгла 50 стори-поинтов за месяц, но вы добавили требований на 80. Когда мы, по-вашему, встретимся?».
Заставьте Владельца Продукта (Product Owner) принимать жесткие решения. Если дата релиза зафиксирована, верхняя линия обязана стать горизонтальной. Любая новая фича заходит в бэклог только через правило обмена: добавили новую гипотезу на 5 поинтов — немедленно выкинули старую на 5 поинтов.
Используйте график для выявления «теневых задач». Если верхняя линия постоянно дергается внутри спринта, значит, стейкхолдеры закидывают тикеты напрямую разработчикам, минуя фильтры. Скрам-мастер (Scrum Master) обязан пресечь этот хаос, защитив фокус инженеров.
Главная мысль
Burnup Chart — это бронежилет для команды разработки. Он защищает инженеров от обвинений в медлительности и заставляет бизнес взять на себя ответственность за хаотичное раздувание бэклога. Управляйте объемом работы, жестко фиксируйте верхнюю линию графика, иначе вы будете вечно гнаться за горизонтом.
Часто задаваемые вопросы (FAQ)
Burndown показывает только остаток работы, смешивая скорость команды и добавленные задачи в одну непонятную кривую. Burnup разделяет их: вы четко видите, сколько кода написано и сколько новых требований прилетело от заказчика.
Да, но его реальная мощь раскрывается на уровне релиза или Эпика. Внутри двухнедельного спринта скоуп меняться не должен (Цель Спринта фиксирована). Если верхняя линия растет внутри спринта — ваш Scrum сломан.
Вы никогда не выпустите продукт. Скорость генерации идей равна скорости написания кода. Владелец Продукта обязан немедленно заморозить бэклог (сделать верхнюю линию плоской) и отрезать лишние фичи, иначе проект просто сожжет весь бюджет.
В Story Points или количестве задач (Throughput). Не используйте часы. Часы врут и не отражают реальную сложность добавленных требований.
Исключительно Владелец Продукта. Если скоуп бесконтрольно пухнет, значит, PO не умеет говорить «нет» стейкхолдерам и не фильтрует гипотезы через Цель Продукта.