✒️ Обязательные встречи при организации работы по #Scrum. Backlog refinement

В прошлой статье по организации работы я познакомил вас с основными ценностями в Scrum. Сейчас же мы коснемся обязательных встреч для команды. Рассмотрим какие они есть и для чего придуманы.

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

Обязательные встречи для каждой команды

Всего обязательных встреч четыре. Все они изначально ограничены по времени и не могут длиться дольше максимального времени. Для всех дальнейших расчетов мы будем считать:

- длительность нашего спринта 2 недели
- размер всей команды семь человек (пять разработчиков + скрам-мастер + продакт менеджер(PM)).

Все расчеты взяты из моего личного опыта.

Встречи:

1️⃣ Планирование - максимум 1 час

2️⃣ Ретроспектива - максимум 2 часа

3️⃣ Спринт ревью - максимум 2 часа

4️⃣ Backlog refinement (груминг) - максимум 4 часа (разбито на две встречи)

Итак, мы видим, что на встречи в спринт каждый член команды максимум потратит 9 часов. Двухнедельный спринт у нас 60-80 рабочих часов. Тогда на встречи уходит всего 12% времени. И это максимум. А кто-то говорит, что встреч много и работать некогда?

Смысл и польза встреч

Самое главное для любой встречи - польза, которую она приносит. Мы все ненавидим бессмысленные митинги, которые кончаются ничем. Давайте разберем какую пользу должна приносить каждая встреча и что нам для этого нужно сделать. В этой статье мы остановимся на Груминге и в последующих раскроем остальные встречи.

🔨 Backlog refinement (груминг)

Раньше все называли встречу ”Груминг”, но оказалось, что это не очень приличное слово в английском языке. Придумали замену - бэклог рефайнмент.

Эта встреча нам нужна для

- Оценки трудозатрат для задач

- Синхронизации понимания всех членов команды того, как делать задачу

Оценка трудозатрат может производиться в удобных вам единицах. Могут быть дни, часы, сторипоинты или размеры (xs, s, m и тд). Мы работаем со сторипоинтами. Такая оценка абстрактна и мне очень нравится. Если голосовать часами, то разработчики заведомо набрасывают сильно больше. Они боятся, что вы посчитаете их часы работы и окажется, что время вышло. У нас самая маленькая задача это 0,5 сторипоинта и самая большая - 13. Больше мы просто не берем и заставляем PM делить на более мелкие.

Хочу отдельно акцентировать внимание на втором пункте. Каждый член команды должен, хоть примерно, понимать алгоритм разработки задачи. На этой встрече задается больше всего вопросов по архитектуре, деталях и необходимых шагах и ресурсах. Очень важно, чтобы каждый член команды понимал алгоритм реализации таски. Этого можно достичь постоянно задавая такие вопросы:

- Всем ли понятно, как делать задачу?
- У кого еще есть вопросы по задаче?
- Какие для этой задачи могут возникнуть подводные камни?
- Хватает ли нам информации для реализации данной задачи?

Подготовка

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

Круто еще иметь карточки для каждого с нарисованными сторипоинтами/другой оценкой. Посмотрите Planning Pocker и подберите себе подходящий вариант.