Планирование спринта

Основные этапы планирования
PO
DevTeam
Что нам нужно сделать?
Почему нам это нужно сделать?
Как мы будем это делать?

Детализация этапов планирования и кто лидирует каждый подэтап?
Обозначение Цели спринта
Пояснение элементов Бэклога
Декомпозиция задач
Оценка задач
Формирование Бэклога спринта
Уточнение Цели
спринта
Подготовка бэклога продукта
Организация встречи
Команда разработки
Владелец продукта
Скрам
мастер
PBR (актуализация бэклога)

Организация встречи
7 Ps Framework

Purpose
Применяем технику "5 почему". Первый вопрос будет звучать так: "Почему я хочу организовать встречу?“
Почему вы решили, что сегодняшняя встреча необходима?
Какие проблемы вы пытаетесь решить этой встречей?
Почему встреча нужна именно сейчас?
People
Кто будет участвовать во встрече и кто вообще нужен, чтобы достигнуть ее цели?
На какого повлияет принятое решение?
Чья точка зрения и согласие важны настолько, что они должны присутствовать лично или направить своих представителей?
Product
Какой результат встречи должен получиться? Как измерить, что мы достигли результата?
Какие артефакты должны появиться после встречи?
В каком виде нужны итоги встречи? В какой срок они нужны? Есть ли корпоративные требования к оформлению?
Какие знания или убеждения должны появиться у участников после встречи?
Process
Повестка встречи, способы принятия окончательных решений, кто будет фасилитировать встречу.
Какие рамки и ограничения для встречи?
Pitfalls
Продумываем возможные сложные ситуации, которые могут возникнуть на встрече и то, как их решать.
Какие риски, как ими можно управлять?
Какие правила нужно установить в начале встречи?
Вопросы, которые прямо не связаны с темой дискуссии и не должны обсуждаться, но могут быть подняты в процессе
Preparation
Что нужно подготовить перед встречей?
Может быть, участникам нужно выполнить какое-то «домашнее задание»?
Есть ли возможность провести предварительный опрос участников перед встречей?
Practical Concerns
Где и во сколько будет проходить встреча?
Достаточно ли всем будет места?
Какое оборудование может понадобиться?
Нужно ли заранее зарезервировать помещение?
Детали 7Ps фреймворка

Подготовка бэклога продукта
У владельца продукта есть ответ на вопрос "Чего самого важного нужно добиться в этом спринте?"
Незавершенные элементы бэклога предыдущего спринта возвращены в бэклог продукта
Бэклог продукта упорядочен
Верхние элементы бэклога продукта максимально соответствуют I.N.V.E.S.T и DoR

Обозначение цели спринта
Вопросы для владельца продукта, которые помогают прояснить цель спринта:
Зачем мы вообще решили запустить спринт?
Зачем мы решили потратить время работы команды (деньги) на ближайший спринт?
Как мы узнаем, что достигли цели? Что должно измениться?

Пояснение элементов бэклога
Владелец продукта поясняет команде бизнес-контекст элементов бэклога продукта
Команда учитывает результаты прошедшего обзора спринта
Приглашенные эксперты отвечают на вопросы команды

Декомпозиция элементов бэклога
6 ключевых паттернов декомпозиции
Уточнение необходимой работы и выделение ее в Jira SubTask
Формирование критериев приемки задач

Ключевые паттерны декомпозиции

Отправить запрос
на сессию
Зачем декомпозировать?
Добавить запрос
на сессию
Редактировать запрос
на сессию
Просматривать запрос на сессию
Удалить запрос на сессию
Так понятнее
Отсекаем ненужные части
Быстрее можем получить обратную
связь
Работа команды
становится прозрачнее
Уменьшаем риски
Снижаем уровень неопределенности
Начать заканчивать запланированные истории
Команда начинает обретать чувство законченности, и веру в свои силы
Распараллеливание работы
Время выполнения сокращается и растет DF
Проще понять что делать
Тестировать проще

Как можно декомпозировать?
Горизонтально – технико-центрированный подход. Удобство для разработки, невозможность получить обратную связь по результату реализации каждой отдельной части. Обычно разбиваются по компонентам или типам работ (функциям).
Вертикально – клиенто-центрированный подход. Польза для клиента или пользователя продукта, возможность получить обратную связь по результату реализации, а владельцу продукта легче приоритезировать на основе бизнес-пользы. Могут участвовать несколько компонентов или типов работ (функций).

Критерии хорошей истории – INVEST*
* INVEST – это акроним, пришедший из XP. Сам акроним подразумевает в себе, чтобы создать хорошую историю необходимо инвестировать время

Какой паттерн декомпозиции выбрать?
Так как одну и ту же пользовательскую историю можно декомпозировать разными способами, вот 3 правила, которые помогут выбрать наиболее подходящий паттерн:
Выберите способ, который позволит вам понизить приоритет части получившихся историй или вообще их не делать
Выберите способ, который позволит разбить историю на равные по размеру маленькие истории
Выберите способ, который позволит избавиться от зависимостей или хотя бы уменьшить зависимости от других историй

По операциям
Когда использовать?
Когда история – о том, чтобы управлять чем-то
или конфигурировать что-то
Что это за способ?
Разделение истории по различным типам операций с данными (CREATE, READ, UPDATE, DELETE)
Полезные вопросы
Какие из операций являются действительно необходимыми для работы с тем или иным объектом?
Все ли операции нужны прямо сейчас?
Каким образом необходимо реализовать каждую из операций?
Как владелец ресторана,
я хочу управлять профилем своего ресторана на сайте, чтобы люди могли заказывать в нём еду
Как владелец ресторана,
я могу создать профиль ресторана
Как владелец ресторана,
я могу изменить профиль ресторана
Как владелец ресторана,
я могу просмотреть профиль ресторана
Как владелец ресторана,
я могу удалить профиль ресторана

По интерфейсам
Когда использовать?
Когда можно получить одни и те же данные через разные интерфейсы
Что это за способ?
Разделение истории, имеющей дело со сложным интерфейсом, на истории, инкрементально добавляющие сложность
Полезные вопросы
Какой самый простой пользовательский интерфейс мы можем предоставить пользователю уже сейчас?
Все ли интерфейсы нужны прямо сейчас?
Есть ли интерфейсы, которые труднее поддержать, чем остальные?
Как потребитель, я могу видеть меню, чтобы я мог выбрать, что хочу съесть
Как потребитель,
я могу видеть меню в PDF
Как потребитель,
я могу видеть меню как web-страницу
с поиском
Как потребитель,
я могу видеть меню
в браузере Chrome
в удобном виде
Как потребитель, я могу в мобильном приложении посмотреть меню
Как потребитель,
я могу видеть меню
в браузере Safari
в удобном виде
Как потребитель, я хочу сделать заказ, чтобы я мог что-нибудь поесть
Как потребитель,
я хочу сделать заказ
на мобильном устройстве
Как потребитель,
я хочу сделать заказ через IVR меню
Как потребитель,
я хочу сделать заказ на сайте
Как потребитель,
я хочу сделать заказ по телефону

По этапам или фазам бизнес-процесса
Когда использовать?
Когда изначальная история описывает этапы или бизнес-процесс
Что это за способ?
Определите конкретные шаги в workflow. Разложите workflow на стадии, сделайте множество историй для инкрементальной (пошаговой) реализации процесса
Полезные вопросы
Какие шаги совершает пользователь, нарисуйте цепочку шагов?
Все ли шаги необходимы прямо сейчас?
Можно ли упростить шаги?
Можем ли реализовать сначала базовые шаги?
Как потребитель, я хочу сделать заказ, чтобы я мог что-нибудь поесть
Как потребитель,
я могу видеть блюда в меню
Как потребитель,
я могу выбрать блюда, которые хочу заказать
Как потребитель,
я могу просмотреть заказ
Как потребитель,
я могу подтвердить заказ

По бизнес-правилам
Когда использовать?
Когда история содержит разнообразные бизнес-правила, что часто можно увидеть по большому количеству примеров
Что это за способ?
Разделите историю, чтобы сложные бизнес-правила были
в отдельных историях. Фактически мы определяем набор сценариев, по которым может выполняться процесс при выполнении тех или иных правил\условий.
Частный случай этого – выделить валидацию вводимых данных в отдельную историю
Полезные вопросы
Какие правила или условия относятся к этой истории?
Все ли эти правила или условия нужны прямо сейчас?
Будет ли упрощённых правил или условий достаточно прямо сейчас?
Как потребитель, я могу использовать кредитную карту для оплаты заказа
Как потребитель, я хочу узнать, если ввёл номер карты
в неправильном формате
Как потребитель,
я хочу узнать, если указал неправильный срок действия
Как потребитель,
я хочу узнать, если не указал имя владельца карты

По типам данных и параметрам
Когда использовать?
Когда история имеет дело с разными группами или типами данных
Когда решение должно поддерживать несколько опций
Что это за способ?
История делает одно и то же для разных наборов данных. Создайте по истории на каждый набор.
Полезные вопросы
Какие основные элементы данных нам необходимы?
Какие элементы данных не нужны прямо сейчас?
Как потребитель, я хочу видеть меню на своём родном языке, чтобы я мог решить, что хочу съесть
Как потребитель,
я хочу видеть меню
на французском языке
Как потребитель,
я хочу видеть меню
на испанском языке
Как потребитель, я хочу видеть информацию о блюде, чтобы я мог решить, что хочу съесть
Как потребитель,
я хочу видеть название и описание блюда
Как потребитель,
я хочу видеть ингредиенты блюда
Как потребитель,
я хочу видеть информацию
о пищевой ценности
Как потребитель,
я хочу видеть картинки блюда

Как потребитель, я хочу видеть меню на выбранном мной языке, чтобы я мог выбрать,
что хочу
Спайки – последний шанс
Когда использовать?
Когда команда понимает, что не уверена
в реализации истории и ей необходимо сначала провести некоторое исследование
Что это за способ?
Выделите из истории необходимые исследования, которые необходимо провести до её реализации
Полезные вопросы
Какие 1-3 вопроса не дают нам начать работу над историей?
Сколько времени мы готовы выделить на исследование?
Спайк: исследовать функциональ-ность перевода

Оценка элементов бэклога и работы в спринте
Относительные оценки и Story Point
Planning Poker
Magic Estimation
Абсолютные оценки в человеко-днях или человеко-часах

Виды оценок
Абсолютная оценка – оценка некоторой величины в абсолютных единицах, размер которых является стандартным. Например: в килограммах, в метрах, в часах, в Джоулях.
Относительная оценка – оценка соотношения двух или нескольких величин друг относительно друга. Например: “первая величина в два раза больше, чем вторая”.

Что такое Story Point?
Относительная единица:
1 SP не важен, важно соотношение
Общие усилия команды:
вся команда оценивает весь PBI (не оцениваем отдельно анализ, разработку, тестирование и т.д.)
Story Point (SP) – это относительная единица измерения общих усилий команды, которые требуются для реализации элемента продуктового бэклога (Product Backlog Item, или PBI).

Идеология
1) Командное обсуждение и достижение консенсуса
2) Оценка командных усилий, а не индивидуальной производительности
3) Использование исторических данных и опыта всех участников команды
4) Оценка размера работы, а не длительности выполнения

Шкала Story Point
1 2 3 5 8 13 21 40 100
Сложность, Неопределенность, Риски
Маленькие
Средние
Большие
Очень большие

От чего зависит оценка в SP?

Planning Poker
Всей командой, включая SM и PO, но они не могут влиять на команду
PO объясняет задачу команде и команда задаёт уточняющие вопросы
Если нет вопросов, то выкидываем карты рубашкой вверх и ждем пока все выкинут карты
Открываем все карты
Кто выкинул самые маленькие и самые большие значения:
Объясняют почему они приняли именно такое решение, чтобы расширить понимание команды по задаче
Команда задает вопросы, обсуждает
Повторяется итерация, начиная с пункта 1
6. Максимальное количество итерация для достижения консенсуса в оценках = 3
7. Если нет консенсуса, то выбирается наибольшее значение или считаем среднее и выбираем ближайшее к среднему, или выбираем значение у которого наибольшее количество карт
8. Оцениваем размер, а не длительность

Magic Estimation
Всей командой
Делим горизонтальное пространство от “самая маленька задача” до “самая большая задача”
Добавляем еще одно пространство “Parking Lot”. Сюда выносятся задачи, которые нельзя оценить, так как абсолютно не хватает информации
Режим молчания
Нужно расположить задачи от “самой маленькой” до “самой большой” задачи
Задачи одного размера объединяем в одну вертикальную группу
Если есть вопросы, то задачу не обсуждаем с другими участниками команды, кроме PO
Режим свободного обсуждения
Каждый участник команды, кроме PO, смотрит что получилось
Если участник команды хочет переместить задачу или уточнить почему именно такой размер, то обсуждение идет уже с другими участниками команды и PO. После обсуждения команда принимает решение, нужно ли поменять расположение задачи
Двигаемся слева направо
Если есть задачи, которые нельзя оценить, то выносим их на “Parking Lot”
Обсуждаем все вместе с PO задачи из “Parking Lot”, если информации стало достаточно, то делаем оценку
Режим вопросы от PO
PO смотрит что получилось и если ему нужно дополнительно обсуждение по выбранному размеру задачи, то он их помечает красным стикером
Происходит обсуждение с командой задач, которые пометил PO. Если все прояснилось, то снимаем красный стикер, если не прояснилось то вопрос к PO “Какой информации не хватает, чтобы сложилось понимание по выбранному размеру?”. Если все таки не удалось достичь консенсуса, то остается размер, который выбрала команда

Формирование бэклога спринта
Валидация по данным о производительности (Velocity)
Валидация по доступности участников команды в спринте
Улучшения с прошлой ретроспективы добавили в спринт

Уточнение цели спринта
Коррекция цели спринта
Насколько команда уверена в достижимости поставленной цели?
Что нужно скорректировать?
Привязка задач к целям кластера или трайба

А в итоге то что?

Итоги планирования
Определили цель спринта
Команда понимает критерии достижения цели и ожидаемый результат в конце спринта
Определили бэклог спринта, направленный на достижение цели спринта
Создали план работ на ближайшие 1-3 дня
Заложили буфер в 5-10% на непредвиденные обстоятельства
Улучшения с прошлой ретроспективы над которыми будем работать взяли в спринт
Определили дату проведения обзора спринта и заинтересованных лиц
Оценили реалистичность поставленной цели с учетом ограничений

В чем роль скрам-мастера на планировании?