Давайте еще раз вспомним как выглядит эта диаграмма.
В данном примере рассмотрен 10-дневный спринт. В нем мы видим, что прошло 2 дня(поскольку
только первые 2 сегмента закрашены зеленым графиком).
Также мы видим общий объем спринта - это
пунктирная линия, которая показывает, что общий объем спринта в пн в 10:00, вт в 10:00 и среду в
10-00 не изменялся и равен 17 SP (Story Points).
По методологии
Scrum,
общий объем работы внутри спринта не изменяется в течение спринта, поэтому эту линию
строят
часто сразу на весь спринт (все 10 дней). Также она помогает оценить сколько осталось сделать
более наглядно, чем если бы она заканчивалась на третьем дне в текущем варианте.
Реальное сгорание (зеленый график) показывает фактически оставшуюся работу. Т.е.
сейчас выполнен командой 1 Story
Point из 17, которые необходимо выполнить для успешного завершения спринта. Выполненной чаще
всего считается задача в статусе "Done" (что такое Done для каждой команды, команда определяет
сама. Есть даже специальный артефакт, который называется DOD - Definition Of Done - он у каждой
команды свой и в нем очень точно описано что означает, что задача выполнена и ее можно подвинуть
в статус "Done". Чаще всего это "Выкачено на прод", но могут быть нюансы. В общем, по текущему
графику мы понимаем, что выполнен DOD только у одной истории, которую команда оценила в 1 SP.
Идеальное сгорание показывает на какой точке должен находиться график реального
сгорания в случае абсолютно равномерной работы. Т.е. на данный момент должно быть выполнено 3 SP
при абсолютно равномерной работе.
Я подозреваю, что может быть интересно понимание что такое Story Point. По сути,
1 SP у одной
команды и 1 SP у другой команды могут скрывать за собой
разный объем работы. У нас, например, есть команды с одинаковым количеством человек, но у одной
емкость на спринт 17 SP, а у другой 35SP. И это нормально. Дело в том, что команда сама выбирает
для себя эталонную задачу относительно которой оценивает все задачи на грумингах (устаревшее
название - это еженедельная встреча, на которой PO приносит User Stories на оценку, а команда
оценивает их посредством покера планирования) (В SAFe это PBR
- Product Backlog Refinement).
Таким образом, мы можем иметь эталонную User Story "Я, в роли водителя автомобиля, хочу после
заправки автомобиля, иметь возможность при необходимости получить напечатанный на бумаге
чек". Договориться, что она для нашей команды 8SP. И, когда PO рассказывает новую User Story,
которую мы должны оценить, мы ее уже оцениваем относительно эталонной задачи. Соответствнно,
новая уже может оцениваться командой в 5 SP, например и т.д. все истории беклога получают свои
оценки.
Емкость команды рассчитывается исходя из статистики. В первые 1-2 спринта замеряется количество
SP, которые команда закрывает и высчитывается среднее значение, на это значение и происходит
планирование (когда PO набирает задачи в спринт из беклога на определенную ёмкость).
Надеюсь, я достаточно понятно расписал как получаются значения на Burn Down Chart.