Burndown chart: как следить за сроками проекта в гибкой методологии

Burndown chart — как следить за сроками проекта в гибкой методологии (диаграмма сгорания)

Burndown chart — это диаграмма, которая показывает, как быстро команда «сжигает» объём работ в спринте: по ней можно понять, выйдете ли вы в срок через 1–2 минуты просмотра, но ключевой риск — самообман (когда «прогресс» рисуют закрытием задач, а не готовым результатом).

Почему это вообще работает (и почему часто не работает)

Страх номер один у людей в Agile: «вроде бежим, а куда — непонятно». Burndown как раз про это: он визуализирует разницу между планом и фактом. Не магия, а термометр. Лечить не умеет, но температуру показывает честно — если вы не подрисовываете градусник маркером.

Парадокс: одна и та же диаграмма в зрелой команде экономит недели, а в начинающей превращается в инструмент корпоративного театра. Причина простая: burndown измеряет не «усилия», а объём оставшейся работы. Если вы не умеете нормально дробить задачи и фиксировать «Definition of Done», график будет красивый, а релиз — грустный.

Как устроена диаграмма сгорания: что на осях и что считается нормой

Оси и линии

X (горизонталь): дни спринта (или недели, если вы смотрите релизный burndown).
Y (вертикаль): объём оставшейся работы — чаще всего story points, иногда часы.
Ideal line: идеальное «сгорание» — линейное снижение от планового объёма до нуля.
Actual line: фактическое сгорание — что реально происходит.

Спринтовый vs релизный burndown

Тип диаграммы	Что показывает	Когда полезна	Типичная ловушка
Sprint burndown	Сгорание задач внутри 1 спринта	Ежедневный контроль «успеваем/не успеваем»	Закрывают задачи в последний день — график «обрывом», а не работой
Release burndown	Сгорание беклога до релиза	Планирование сроков для стейкхолдеров	Скоуп растёт быстрее сгорания — и все делают вид, что так и было

Практический вывод: для команды — спринтовый; для бизнеса — релизный. Если выбирать один, берите спринтовый: он раньше показывает, что вы «приплыли».

Burndown как инструмент контроля сроков: что именно он вам даёт

1) Ранний сигнал, что дедлайн под угрозой

Если фактическая линия стабильно выше идеальной — вы отстаёте. Если ниже — вы либо молодцы, либо неверно оценили. И вот тут начинается взрослая часть: burndown показывает симптом, а причину вы ищете уже на дейли и ретро.

Подводный камень: пытаться «догнать график» закрытием мелочёвки, оставляя сложные задачи на потом. На графике красота, в продукте — дырка.

2) Контроль изменения объёма (scope)

Burndown хорошо ловит «ползучий скоуп». Если по ходу спринта вы добавляете задачи (или переоцениваете их вверх), линия может идти не вниз, а вверх. Это не ошибка диаграммы — это честный сигнал: вы меняете контракт.

Практический вывод: любые добавления в спринт должны быть осознанными. Иначе спринт — не спринт, а «неделька хаоса».

3) Понимание реальной скорости команды

Burndown напрямую связан с velocity, но не равен ему. Velocity — сколько вы «сожгли» за спринт. Burndown — как именно это происходило по дням. Для прогноза сроков важны оба: скорость + стабильность.

Подводный камень: сравнивать velocity разных команд. Story points — локальная валюта, не доллар США.

Как построить burndown chart без боли (и без Excel-колдовства)

Шаги

Определите единицу измерения: story points (лучше) или часы (можно, но для саппорта/ops чаще).
Зафиксируйте Definition of Done: что значит «задача сгорела» — код в main? тесты? деплой? принял PO?
Оцените и запланируйте спринт: сумма поинтов = стартовое значение на Y.
Ежедневно обновляйте статус: задачи «сгорают» только когда реально Done.
Не прячьте изменения объёма: если добавили работу — это должно отражаться (иначе график становится фанфиком).

Практический вывод: корректный burndown — это дисциплина «Done значит Done». Всё остальное — вариации на тему.

Типовые паттерны на графике и что они означают

Как выглядит	Что это обычно значит	Что делать
Длинная горизонтальная линия, потом резкое падение в конце	Закрывают задачи пачкой в последний день (или «почти готово» висит неделями)	Дробить задачи меньше, внедрить WIP-лимиты, требовать DoD
Линия «зубцами» вверх-вниз	Переоценки, добавления в спринт, нестабильный поток	Фиксировать причины изменений, защищать спринт от внезапных хотелок
Факт стабильно выше идеала	Переоценили возможности, много блокеров, недоформулированный беклог	Улучшать refinement, убирать зависимости, уменьшить коммитмент
Факт сильно ниже идеала с первых дней	Недооценили, взяли слишком мало, или points «нарисованы»	Пересмотреть оценку, добавить задачи (осознанно), нормализовать планирование

Скрытая цена: почему burndown может вредить

Диаграмма — простой инструмент, но люди сложные. Если burndown превращают в KPI, команда начинает оптимизировать «красоту линии», а не поставку ценности. Начинается микроменеджмент, дробление до абсурда и закрытие задач ради закрытия.

Цена №1: падает качество (Done становится «почти done»).
Цена №2: растёт техдолг (лишь бы успеть к дате).
Цена №3: исчезает правда о рисках (никто не хочет портить график).

Практический вывод: burndown — для диагностики и разговора, а не для наказаний.

Экспертный вердикт и инструмент: чек-лист «живого» burndown

1) “Done” означает поставлено пользователю (или хотя бы готово к релизу), а не «у меня на ноуте работает».
2) В спринт не добавляют задачи без снятия эквивалентного объёма.
3) Средний размер задач — 1–2 дня, а не «эпик на две недели».
4) На дейли обсуждают блокеры и план, а не оправдывают линию графика.
5) После спринта есть ретро с выводом: почему линия была такой, и что меняем в процессе.

Частые вопросы

Burndown chart обязателен в Scrum?

Нет. Scrum требует прозрачности и эмпирики, а burndown — один из способов визуализации. Если вам лучше заходит cumulative flow или burnup — используйте их, лишь бы метрика помогала принимать решения.

Что лучше: story points или часы?

Для продуктовой разработки чаще лучше story points: они меряют относительную сложность и меньше провоцируют торг «а почему не 6 часов, а 5». Часы уместны там, где работа повторяемая и потоковая (например, часть ops/саппорта).

Почему линия падает только в конце спринта?

Обычно потому, что задачи слишком большие, тестирование и приёмка сдвинуты к финалу, а “почти готово” не считается Done. Лечится дроблением задач и ранней интеграцией/тестами.

Можно ли добавлять задачи в спринт и не ломать burndown?

Можно, но тогда вы меняете план. Честный вариант — добавили новую задачу, убрали из спринта равноценный объём. Нечестный — просто добавили и удивляетесь, почему «Agile не работает».

Burndown показывает продуктивность разработчиков?

Нет, и лучше не пытаться. Burndown показывает динамику выполнения командного плана. Если использовать его как рейтинг людей, вы получите красивые графики и плохой продукт (проверено индустрией).

Чем burndown отличается от burnup?

Burndown показывает оставшуюся работу, burnup — выполненную работу на фоне общего объёма (и лучше визуализирует рост скоупа). Если у вас часто меняется объём требований, burnup обычно честнее.

Если хочешь, могу адаптировать материал под конкретный контекст: Scrum/Канбан, Jira/YouTrack/Trello, продуктовая команда или аутсорс — там разные типовые «поломки» burndown и разные лекарства.