Як вираховувати значення в Burn Down Chart у Scrum

Після публікації серед друзів першої статті про Burn Down Chart, у коментарях друге питання, яке було задане: "Не зрозуміло як вираховуються всі ці значення". Тому в цій статті я постараюся розповісти про те, як ми рахуємо щоденні значення на Burn Down Chart. Як завжди, буду радий усім коментарям колег, якщо раптом щось скажу не так, але все ж хочеться вірити, що тема достатньо зрозуміла для мене.

Давайте ще раз згадаємо, як виглядає ця діаграма.

У цьому прикладі розглянуто 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.