Планирование спринта — Capacity vs Velocity

Хороший план сегодня лучше безупречного плана завтра. (Джордж Паттон)

На протяжении многих лет я экспериментировал с двумя различными подходами планирования спринта и объема работ. Вот мои мысли об этом:

• Capacity (Вместимость) — подсчитывается общее количество часов, доступных в команде. Затем пользовательская история с наивысшим приоритетом берется и разбивается на задачи. Каждое задание оценивается в количестве часов. Если остается свободное время, берется следующая высокоприоритетная пользовательская история, и процесс продолжается до тех пор, пока доступных часов не останется.
• Velocity (Скорость) -– измеряется в терминах стабилизированного количества Story Points, которые команда может доставить за один спринт заданной длины и с заданным Definition of Done (определением «Готово»). Команда, опираясь на свою интуицию, должна решить могут ли они взять дополнительную работу или остальные истории должны быть отложены на следующие итерации. Как только определённое количество Истории взято в спринт, каждая из них должна быть разбита на задачи и оценена.

Давайте рассмотрим оба подхода.

Планирование на основе Capacity (вместимости) спринта

Преимущества:

Команда может совместно проектировать и разбирать задачи. Декомпозиция Историй на небольшие задачи вовлекает всю команду в принятие решений и, как результат, команда владеет собственным кодом.

Недостатки:

• Предполагается, что все оценки точны — При определении размера спринта на основе доступной емкости предполагается, что все оценки задач точны, но эвристика доказывает обратное. Поэтому многие команды не выполняют свои обязательства и, как следствие, начинают планировать с большим запасом, либо привыкают к тому, что каждый спринт не выполняют задуманного, что вызывает синдром кипящей лягушки (Boiling Frog syndrome во всей команде.
• Предполагается, что все задачи могут выполняться параллельно — Для команды из 5 человек, в 10 дневном спринте с нагрузкой 6 часов в день на человека, емкость рассчитывается как 300 часов. Затем команда выбирает историй, размер которых суммарно не превышает 300 часов. Ожидается, что вся команда может работать параллельно во время спринта, что практически недостижимо, если каждая задача не является независимой.
• Предполагается, что все в команде равны — Идеальная скрам-команда состоит из набора разных навыков, опыта и уровня знаний. Возможности каждого члена команды различаются, поэтому время на выполнение задач тоже будет различаться в зависимости от участника команды. Этот важный факт часто игнорируется при оценке задач.
• Закон Паркинсона — Работа заполняет время, отпущенное на неё. Кто-то, обычно Скрам-мастер, должен постоянно указывать на излишний перфекционизм при выполнении работы или на поведение участников команды, которые прячут за оценками своё безделие. Всё это в конечном итоге приводит к проблемам доверия, если в команде отсутствует прозрачность.
• Делает покер-планирование бесполезным — Если команда не использует размеры Истории для планирования спринта, тогда все упражнения по их измерению становятся для команды неактуальным. Так как команда не видит большой ценности в размерах Историй для планирования спринта, цель покера планирования не будет достигнута, и при планировании релизов будет трудно достичь консенсуса.

В результате команды вынуждены выяснять «почему они постоянно не выполняют свои планы» и искать решения на ретроспективе спринта. Но команда не в состоянии изменить процесс целиком. Поэтому, команда обычно придумывает обширный список задач, которые нужно сделать, чтобы решить проблемы. Большинство из таких задач являются бесполезными или неважными и приводят к сокращению объёма спринта.

Планирование основанное на Velocity (Скорости) команды

Выполнение спринта на основе скорости команды устраняет вышеуказанные проблемы и имеет некоторые дополнительные преимущества:

• Учёт неопределенности при планировании — Поскольку размер Истории представляет собой смесь усилий и неопределенности, История с, скажем, 13 или 21 баллом займет большую часть спринта, даже если оценка всех задач по времени займёт в общем не так много часов.
• Предсказуемое планирование релизов — Since the team uses velocity for sprint planning the consistency of the practice encourages an effective planning poker. The detailed sizes of the stories can lead to a more value added release planning with the identified dependencies/assumptions and their impact over the release flow.
• Учёт рисков в Истории — velocity driven commitment encourages through the completion of the story in all the aspects. Hence, overhead or waste is implicitly accounted while committing the sprint goal. When team inspects to increase the velocity, they will point out the waste that is affecting the velocity most and the stakeholders can work on it.
• Внедряет культуру уважения к обязательствам — Поскольку команда при планировании берёт Истории опираясь только на свой опыт в предыдущих спринтах, со временем получается число Story Point’ов, которое команда может с большой вероятностью выполнять. После нескольких Спринтов команда вырабатывает свой темп и построенная культура заставляет избавляться от ненужного или проверять свои собственные процессы разработки, инициируя непрерывное улучшение.

Планирование спринта самый нижний уровень планирование и без понимания того, КУДА и КАК вы идёте любая работа становиться бесполезной. На эти вопросы помогает ответить Roadmap. О подходах к составлению Roadmap продукта поговорим в следующей статье.

–> (Составляем Roadmap продукта: типичные ловушки и как их избежать)

Помните, Scrum не решает ваши проблемы. Scrum показывает вам ваши проблемы. Вы должны решить проблемы самостоятельно. (Рон Джеффрис)