Оценка в сторипойнтах помогает сравнить усилия на выполнение одного элемента бэклога с другой работой, которую команда уже понимает. Для полезной сессии покер-планирования договоритесь о шкале, выберите эталонные истории, одновременно покажите оценки, обсудите причины большого разброса и проголосуйте повторно после уточнения объёма работы.
Scrum-доска для планирования спринта позволяет держать перед глазами истории, эталоны и открытые вопросы. В этом примере команда, отвечающая за оформление заказа, разбирает три задачи. Одна из них остаётся без оценки из-за невыясненной зависимости.
Подготовьте истории, которые можно сравнивать
Сторипойнты отражают относительные усилия: объём работы, сложность и неопределённость. В объяснении Mountain Goat Software учитывается и работа, необходимая для выполнения принятого командой Определения готовности. Если для завершения задачи нужны тестирование, интеграция или документация, оценка не может ограничиваться написанием кода.
До сессии для каждой истории опишите результат для пользователя и достаточно подробные условия приёмки. Удалите дубли, разделите несвязанные результаты и отметьте зависимости, которые могут повлиять на работу. Оценка задачи «показать сводку заказа» мало что означает, пока команда не знает, какие поля, состояния и источники данных в неё входят.
В нашем примере команда обсуждает три задачи:
- Заменить название сохранённого адреса «Адрес 1» на подпись, которую выберет покупатель.
- Проверить почтовый адрес через внешнего поставщика сервиса и объяснить покупателю обнаруженные проблемы.
- После оформления заказа показать подтверждение с полями, которые уже возвращает сервис заказов.
Оценку дают те, кто будет выполнять работу. Владелец продукта (Product Owner) объясняет ожидаемое поведение и границы задачи. Фасилитатор ведёт обсуждение и записывает вопросы. В Scrum за оценку размера элементов бэклога отвечают разработчики; сам фреймворк не требует конкретной шкалы или покер-планирования.
Выберите эталоны и одну шкалу
Эта команда использует значения 1, 2, 3, 5, 8 и 13. Выберите шкалу до голосования и придерживайтесь её. Возможны и другие шкалы, но переключение между ними в пределах одной сессии затрудняет сравнение.
У команды два эталона из уже выполненной работы: редактирование подписи сохранённого адреса на два пункта и изменение вариантов доставки на восемь пунктов, для которого потребовались новая логика сервиса и несколько состояний ошибки. Рядом с числами сохраните объём работы и условия её завершения. Эталон полезен потому, что люди помнят работу, а не потому, что число «два» само по себе что-то означает.
Обсудите, к чему новая история ближе: к небольшому изменению подписи или к более сложной интеграции, — и почему. Не приравнивайте один пункт к фиксированному числу часов. Задача на восемь пунктов может требовать больше совокупных усилий, чем задача на два, но не занимать в четыре раза больше календарного времени: на срок влияют доступность людей, параллельная работа и зависимости.
Проведите первое голосование без подсказок
Прочитайте задачу и дайте владельцу продукта ответить на вопросы об объёме до того, как кто-то назовёт число. Затем каждый участник выбирает значение, не показывая его остальным. Раскройте оценки одновременно, спросите авторов самой низкой и самой высокой оценок, какую работу они учли, и предложите остальным добавить пропущенные допущения. Такой порядок описан в руководстве Mountain Goat Software по Planning Poker.
Допустим, четыре участника оценивают изменение подписи сохранённого адреса. Их значения: 2, 2, 3 и 3. Низкие оценки предполагают только изменение отображаемой подписи. Высокие включают доработку проверки адреса. Владелец продукта подтверждает, что проверка адреса и логика доставки остаются прежними. Команда сверяется с эталоном на два пункта, голосует ещё раз и соглашается на 2.
Оценку снизили не ради дедлайна. Из неё исключили работу, которая изначально не входила в задачу. Запишите рядом: «только подпись; проверка адреса без изменений». Так границы будут понятны и тем, кто не присутствовал на встрече.
Разберите расхождения до фиксации оценки
Задача проверки адреса получает оценки 5, 5, 8 и 13. Минимальная оценка предполагает, что существующий сервис уже обрабатывает ответы поставщика. Максимальная включает обработку тайм-аутов, состояние недоступности поставщика и новое решение о том, можно ли покупателю продолжать с непроверенным адресом.
Команда обнаружила нерешённый продуктовый вопрос и техническую неопределённость. Она не берёт среднее и не выбирает 8 только потому, что это число между крайними значениями. Сначала владелец продукта должен определить поведение при недоступности проверки, а инженер — изучить текущую интеграцию. Задача возвращается на уточнение с этими двумя вопросами и ответственными за ответы. При необходимости можно отдельно запланировать исследование: оно должно отвечать на конкретный вопрос, а не обещать реализацию всей функции.
Для подтверждения заказа первый раунд даёт 3, 3, 5 и 5. В высокие оценки включена загрузка квитанции, которой история не предусматривает. Владелец продукта уточняет: нужно показать существующие номер заказа, товары, итоговую сумму и вариант доставки; скачивание квитанции — отдельная работа. Учтя состояния загрузки и отсутствия данных, команда голосует повторно и соглашается на 3.
| Задача оформления заказа | Первый раунд | Уточнение | Зафиксированный результат |
|---|---|---|---|
| Изменить подпись сохранённого адреса | 2, 2, 3, 3 | Проверка адреса не меняется | 2 пункта |
| Проверить адрес через поставщика сервиса | 5, 5, 8, 13 | Неизвестны резервный сценарий и возможности текущего сервиса | Без оценки; вернуть на уточнение |
| Показать подтверждение заказа | 3, 3, 5, 5 | Только существующие поля; без скачивания квитанции | 3 пункта |
Согласованные значения получены после нового обсуждения и голосования, а не усреднением первого раунда. В шкале этой команды нет 4, поэтому расхождение между 3 и 5 не превращается автоматически в четыре пункта. Если оценки по-прежнему сильно различаются, запишите, что ещё неясно, вместо того чтобы создавать видимость точности.
Сохраните оценку и оставшиеся вопросы
Для каждой оценённой задачи сохраните согласованное значение, повлиявшее на него решение об объёме и эталонную историю. Для задачи без оценки запишите вопрос и того, кто на него ответит. История проверки адреса не должна получать ноль пунктов или исчезать с доски: оба варианта скрывают незавершённую подготовку работы.
Две согласованные оценки в примере дают пять пунктов, но эта сумма не означает обязательство выполнить их за спринт. На планировании спринта команда ещё учитывает цель спринта, доступные ресурсы, зависимости и собственные прошлые результаты. Не складывайте свои пункты с пунктами другой команды и не сравнивайте разработчиков по количеству выполненных пунктов. Шкала отражает общее понимание работы внутри конкретной команды.
Если объём меняется с «показать существующие поля» на «сформировать и скачать квитанцию», пересмотрите задачу и её оценку. Сохраните прежнюю заметку об объёме, чтобы изменение было видно. Повторная оценка полезна, когда меняется работа; незаметное исправление числа ради точности старого плана лишает команду материала для анализа.
Соберите обсуждение оценок в Boardmix
Создайте области для эталонных историй, текущей задачи, раскрытых оценок, согласованного объёма и открытых вопросов. Два эталона разместите так, чтобы их видел каждый. Перед голосованием по текущей задаче покажите результат для пользователя и условия приёмки.
Используйте физические карточки или инструмент с закрытым выбором и одновременным раскрытием голосов, а затем перенесите результаты на доску. Числа на общем видимом холсте, появившиеся до завершения выбора, могут повлиять на остальных. В этом сценарии Boardmix хранит историю и запись обсуждения; закрытое голосование проходит отдельно.
Откройте доску Boardmix и разместите на ней эталоны и три задачи оформления заказа. Оставьте рядом с соответствующими историями записи «2 — только подпись», «без оценки — уточнить поведение при недоступности поставщика» и «3 — существующие поля подтверждения», а не просто ряд чисел.
