Scrum poker для Scrum-команд

Scrum poker — так многие Scrum-команды называют покер планирования. Правила у него те же: каждый втайне выбирает карту, карты открывают одновременно, команда обсуждает разброс. На картах обычно стори поинты, поэтому встречается и название pointing poker. Сама механика с разобранным примером описана на странице про покер планирования. Здесь речь о вопросах, которые возникают именно в Scrum: в какой момент спринта оценивать задачи, кто ведёт сессию и что команда потом делает с числами.

Что Scrum Guide говорит об оценке

Об оценке в Scrum Guide сказано совсем немного. Элементы бэклога продукта нужно уточнять, пока они не станут достаточно маленькими, чтобы уложиться в спринт. Оценивают их размер разработчики, которые будут делать работу. Story points, покер планирования, velocity и числа Фибоначчи в гайде не упоминаются ни разу.

Эти практики выросли вокруг Scrum. Story points и velocity пришли в основном из экстремального программирования (XP), а в Scrum-команды их в 2000-х принесли agile-коучи. Поэтому команда может оценивать в поинтах, в идеальных днях, в размерах футболок или не оценивать вовсе и при этом работать строго по Scrum.

Об этом полезно помнить, когда команда начинает тяготиться встречами по оценке. Фреймворк не обязывает их проводить. Оценка нужна, пока помогает команде понимать будущую работу и брать в спринт столько, сколько она успевает сделать. Если с этим она не справляется, её можно поменять или отменить.

Груминг или планирование спринта

Команды проводят scrum poker в двух местах, и от того, где идёт основная оценка, заметно зависит, каким получится спринт.

Оценка на груминге

Груминг, он же рефайнмент (backlog refinement), — постоянная работа с бэклогом: истории уточняют и дробят, пока они не будут готовы к спринту. Во многих командах под это выделяют встречу раз или два за спринт, на час или меньше. Scrum poker здесь на своём месте. Истории попадут в работу только через спринт-другой, так что есть время дождаться ответов от владельца продукта, а слишком большую историю можно разделить задолго до того, как команда за неё возьмётся.

Оценка на планировании спринта

На планировании спринта (Sprint Planning) команда решает, что войдёт в следующий спринт и как она это сделает. Если истории приходят уже оценёнными, планирование проходит быстро: команда сравнивает сумму оценок со своей velocity за последние спринты и поправляет список. Одну-две истории, может быть, придётся переоценить, если после груминга выяснилось что-то новое.

Там, где всю оценку оставляют на планирование, встречи обычно выходят долгими и выматывающими. К пятой неясной истории люди голосуют за то, что быстрее отпустит их с созвона. Если это похоже на вашу команду, попробуйте перенести оценку на груминг.

Скрам-мастер как ведущий

Скрам-мастер, который сам не разрабатывает в этой команде, не голосует. Во время scrum poker он следит, чтобы процесс шёл честно и не буксовал.

До голосования он проверяет, что историю поняли. Тихий вопрос «у кого остался вопрос, который он так и не задал?» часто вытаскивает то, в чём разработчик сомневался, но не решался сказать вслух.

Во время голосования он бережёт тишину. Если кто-то до раскрытия говорит «да это двойка», скрам-мастер может попросить команду переголосовать или просто напомнить, что оценки держат при себе. Обычно пары таких напоминаний хватает, дальше команда следит за этим сама.

После раскрытия он просит авторов крайних оценок объяснить свои карты, всегда в одном порядке и по имени. Когда это становится привычным порядком, оказаться с крайней оценкой уже не так неловко.

Ещё он следит за временем. Мягкий лимит в пять минут на историю не даёт сессии застрять. Если после двух-трёх раундов оценки так и не сошлись, скрам-мастер откладывает историю и договаривается, кто выяснит открытый вопрос.

Хороший ведущий говорит меньше, чем кажется со стороны. Основная польза сессии в том, что разработчики объясняют друг другу свои числа, и скрам-мастер в первую очередь оставляет для этого место.

Если кто-то выложил «?» или ☕

На обе карты нужно реагировать. «?» значит, что истории не хватает информации, и скрам-мастеру стоит выяснить, чего именно. ☕ значит, что команде нужен перерыв, и его стоит дать. Подробно обе карты разобраны на странице о шкале Фибоначчи.

Баги, спайки и техдолг

Scrum-команды регулярно спорят, оценивать ли работу, которая не оформлена как пользовательская история. Единственно верного ответа нет, но решение лучше принять один раз и держаться его.

Баги одни команды оценивают как любой другой элемент бэклога, и они попадают в velocity. Другие не оценивают баги вообще и принимают, что velocity отражает только новую функциональность. Во втором случае velocity проседает в спринтах, где было много багов, и некоторые команды считают это полезным сигналом.

Спайк — исследование с ограничением по времени. Его часто заводят после того, как кто-то выложил «?» на историю. Раз время спайка и так ограничено, многие команды его не оценивают: договариваются о лимите, скажем, в два дня и вычитают это время из ёмкости спринта.

Рефакторинг и обновления зависимостей конкурируют с продуктовыми задачами за один и тот же спринт. Если оценивать техдолг в поинтах, владелец продукта видит, чем приходится жертвовать. Переезд на новую версию фреймворка с оценкой 8 труднее откладывать бесконечно, чем работу, спрятанную внутри других историй.

Scrum poker и velocity

Большинство команд оценивает в поинтах ради velocity, то есть суммы поинтов, закрытых за спринт. По ней решают, сколько брать в следующий спринт. Scrum poker помогает сохранить это число осмысленным: каждую оценку согласует вся команда, и шкала не уплывает, как бывает, когда оценивает один человек. Как считать velocity и какие вокруг неё ходят мифы, описано на странице про стори поинты.

Когда scrum poker не нужен

Многие хорошие команды без него обходятся. Если истории у вас примерно одного размера, можно дробить всё до одного-двух дней работы и считать истории штуками. Это вполне рабочий способ планировать.

Команде из двух-трёх человек может хватить короткого разговора, хотя тайное голосование защищает от якорения и в маленькой группе.

Канбан-команды и все, кто работает непрерывным потоком, часто смотрят на время цикла (cycle time) и отдельные задачи не оценивают вовсе. А если оценки никак не влияют на планирование и прогнозы, тратить на них время незачем: либо начните пользоваться числами, либо перестаньте их производить.

С другой стороны, если команда регулярно берёт в спринт больше, чем успевает, или планирование похоже на гадание, несколько спринтов регулярных сессий scrum poker обычно показывают, где возникает проблема.