Как анализировать отчет по спринту?

Какие инструменты анализа используют в скраме? Какие выводы можно сделать по результатам спринта? Что нового после внедрения скрама?

В прошлой статье уже описывал принцип проведения Демо (Sprint Review) и немного затрагивал отчет по спринту, который заботливо собирает за нас Jira. Очередной этап нашей работы по Scrum в компании находится в стадии Обзора и Ретро, поэтому хотелось бы более подробно разобрать способы анализа имеющихся данных по результатам окончания Спринта.

На этот раз наша Команда завершила четвертую неделю по короткому Спринту (недельному) технической поддержки и впервые закончила длинный Спринт (двухнедельный) крупного проекта.

Scrum отчеты

Отчетов существует множество и каждый использует те, с которыми ему удобно работать. Рассмотрим основной набор в Jira:

1. Диаграмма сгорания задач Burnup Chart - график, отслеживает прогресс выполнения Спринта в значениях решенных задач относительно полного списка задач в Спринте. Используется для мониторинга прогресса выполнения Спринта в направлении положительной динамики.
2. Диаграмма сгорания задач Burndown Chart - график, отслеживает оставшийся объем работ в Спринте. Используется для мониторинга прогресса выполнения Спринта в направлении отрицательной динамики.
3. Отчет о скорости Velocity - гистограмма или столбчатая диаграмма, отслеживает объем выполняемой работы командой. Используется для планирования объема работ на будущие Спринты.
4. Сводный график - отображает динамику изменения статусов задач за выбранный период времени. Используется для определения проблемных моментов времени, в которых накапливается больше всего задач

Пример BurnUp Chart

Опыт анализа отчета по спринту

Мне довелось разбираться с анализом отчетов по Спринту уже на четвертой неделе.

BurnDown Chart недельного Спринта: 4w, Support

BurnDown Chart - это основная диаграмма, которая служит Скрам Команде каждый день (Daily Scrum) удобным инструментом на пути к завершению работы по Спринту.

Как читать отчет

• На графике по вертикали видна оценка объёма оставшегося времени по задачам (можно выводить story points), а по горизонтали - временная шкала. Проблема оценки оставшегося количества часов в том, что у нас не всегда факт затраченного времени вносится сразу, иногда постфактум. Поэтому возможны простои и резкие всплески, а не ступенчатые движения к идеальной кривой.
• Красная кривая линия показывает сколько работы осталось выполнить в Спринте. Серая линия - идеальный график выполнения работ. Зеленая линия (используется не везде) - это объём закрытых часов в Спринте с течением времени. Серое поле (на картинке с 25 по 27 января) отображает нерабочие дни - может быть полезно, если команда трудится и закрывает часы даже в выходные.
• Основная динамика красной линии всегда отрицательная, но периодически присутствуют положительные всплески - это связано с увеличением оценки по имеющимся задачам или добавлением в Спринт новых задач. Зеленая линия всегда с положительной динамикой, потому что время по задачам в процессе работы только затрачивается и не отменяется.

Анализ фактов по Спринту 4w, Support

• Исторические точки: 46 -> 57. Прирост 23% - выше нормы, но мы уже осознанно понимаем, что эта Скрам Команда не сможет прирастать в пределах 10% по той причине, что постоянно приходится оказывать консультацию сотрудникам технической поддержки и ключевым пользователям.
• 7 историй планировалось к выполнению, 10 новых было добавлено.
• 2 ошибки добавлены для срочного устранения, 1 удалена.
• Итого выполнено: 19 задач.

Анализ фактов по Спринту 3-4w

Burndown Chart двухнедельного Спринта: 3-4w

• Опять же видно, что затраченное время по задачам в Спринте было зафиксировано только под конец Спринта, поэтому основная линия оценки оставшегося времени - горизонтальная почти до 24 января.
• Исторические точки: 47 -> 50. Прирост 6% - в пределах нормы 10%.
• 6 задач планировалось к выполнению, 2 новых добавлено (точнее декомпозировано) и 1 удалена.
• Итого выполнено: 7 задач.
• По задачам есть проблема в том, что они оказались слишком объёмными и неподъёмными с пересечением по коротким Спринтам 3w, Support и 4w, Support.

Выводы Демо (Sprint Review) и Ретро (Sprint Retrospective)

1. От stakeholder'ов и группы по планированию и приоритезации работ (они же топ-менеджеры, они же Владельцы Продуктов) есть обратная связь, что не очевиден факт выполнения задачи. Требуется подтверждение реального конечного Заказчика о выполнении задачи, так как топ-менеджеры не владеют полной картиной по всем выбранным задачам. Здесь нужно скорректировать Definition of Done (DoD).
2. В целом по двум Спринтам наблюдаю следующее: длинный Спринт сильно отходит на второй план, работы по нему выполняются очень неохотно. Он растянут на 2 недели - смысла в этом не вижу и думаю, что нужно будет выйти в перспективе на недельные Спринты, в которых можно будет гибко отслеживать результаты даже по проектным задачам: не будет путаницы у Команды за какую задачу хвататься первой и при планировании будет четко ясна производительность (Velocity) Команды.
3. Существует вопрос по Владельцу Продукта (Product Owner) - на текущий момент ответственность за продукт лежит на топ-менеджерах и у меня, как руководителя проектного офиса. Но мы понимаем, что это некорректно, и требуется поставить одного Владельца Продукта, который самостоятельно будет принимать решение по развитию этого продукта. Процесс не должен быть коллегиальным и не должен принадлежать какой-то из зон ответственности бизнеса. Нужен человек без связки с бизнесом, но подробно знающий принцип его работы и принцип работы программных продуктов: 1С:Управление торговлей, 1С:Бухгалтерия, 1С:Зарплата и управление персоналом, 1С:Документооборот.
4. В целом по работе Скрама в проектном офисе могу сказать, что все артефакты стараемся соблюдать, но пока далеки от идеала. Привыкли к Daily Scrum (даже укладываемся по времени, но правда иногда все равно кто-то уходит в подробности), привыкли Планировать Спринты, делать Обзор Спринтов и Ретроспективу. Времени на все события очень мало, потому что задач много - банально не успеваем выделить в одной неделе - суммарно день, чтобы уделить время всему происходящему. Темпы очень большие, работа слишком интенсивная и есть переживание за выгорание Команды.

Подведем итоги

1. Инструменты анализа в Скраме - отчеты, артефакты, события. Основной отчет: диаграмма сгорания задач с резюме работы в Спринте - сколько задач выполнили, сколько не успели выполнить, сколько добавили внеплановых, сколько оценок изменили.
2. Выводы по результатам Спринта - скорость Команды и отклонение от плановых значений, корректная постановка задач Владельцем Продукта и их оценка Командой, общая организация и понимание Скрама в компании.
3. Что нового после внедрения Скрама - видны ошибки и слабые места работы, а значит есть куда расти! Опыт (эмпиризм) в действии, потому что прямая связь с бизнесом и скорость поставки нового функционала налаживается с заметным результатом. Но видно, что некорректный DoD, роль Владельца Продукта, дисциплина на Скрам Событиях нас пока подводят.