Шаблон порядку денного планування спринту для інженерних команд

Чому спринти перевантажуються

У планування спринту є один структурний провал, якому шаблони не запобігають: команди вибирають беклог спринту, перш ніж хтось перевіряє місткість. Результат — спринт, що видавався здійсненним на дошці й розвалюється до середи, коли двоє інженерів відсутні пів тижня, один тикет потроює скоуп, а три елементи мали неозвучені залежності від сервісу, який команда платформи переписує.

Виправлення просте й майже ніколи не робиться: беріть зобов'язання щодо місткості, перш ніж брати зобов'язання щодо роботи. Наведений нижче шаблон починається з огляду місткості саме з цієї причини.

Порядок денний (скопіюйте це)

Тривалість: 2 години для 2-тижневого спринту; 1 година для 1-тижневого спринту
Формат: із ведучим, беклог видимий усій команді

Розділ 1 — Мета спринту (10 хв)

Одне речення: як успішний спринт виглядає ззовні?
Мета має бути достатньо конкретною, щоб будь-який член команди міг наприкінці спринту оцінити, чи ви її досягли
Відкидайте цілі, що є просто списком тикетів («завершити рефакторинг авторизації й сторінку білінгу») — це беклог, а не мета

Розділ 2 — Огляд місткості (15 хв)

Перелічіть кожного члена команди поіменно
Для кожного: заплановане PTO, ротація чергувань, регулярні наради, відомі зовнішні зобов'язання
Виражайте місткість у доступних story points або днях — не в кількості людей
Це число — стеля; не вибирайте більше роботи, ніж воно витримує

Розділ 3 — Вибір беклогу (45 хв)

Пройдіться найпріоритетнішими елементами з відрефайненого беклогу
Для кожного кандидата: чи має команда достатньо, щоб почати, чи є відкриті запитання, що потребують відповідей до старту спринту? Відкриті запитання належать до черги рефайнменту, а не до спринту
Припиняйте вибір, коли досягли 80% місткості; решта 20% поглинає перенесення й незаплановану роботу

Розділ 4 — Критерії приймання (20 хв)

Для кожного вибраного елемента: озвучте критерій, що робить його завершеним
Якщо команда не може озвучити критерій за 60 секунд, тикет недостатньо відрефайнено — поверніть його в беклог
Запишіть це в тикет зараз, у кімнаті; не покладайтеся на «додамо пізніше»

Розділ 5 — Ризики та залежності (15 хв)

Що могло б заблокувати досягнення мети спринту, що команда не контролює?
Назвіть відповідального за залежність; виведіть її назовні зараз, доки є час розв'язати до середини спринту
Нерозв'язані залежності отримують названого відповідального з команди, який їх відстежуватиме

Завершення (15 хв)

Підтвердьте, що мета спринту досі чинна з огляду на вибрану роботу
Призначте секретаря для підсумку спринту або підтвердьте налаштування автоматичного звіту
Підтвердьте дату наступного планування

Що більшість шаблонів планування спринту пропускають

Найпопулярніші шаблони планування спринту зосереджені на грумінгу беклогу й визначенні завершеності. Обидва важливі. Жоден не адресує помилку планування, що продукує найбільше провалів спринту: вибір роботи без перевірки доступності.

Команда з п'яти інженерів на повній місткості має приблизно 200 story points на 2-тижневий спринт. Команда з п'яти, де двоє інженерів у PTO, один на ротації чергувань, а один на триденному офсайті, має, можливо, 110. Якщо ви виберете 180 points у другому спринті, ви вже провалилися. Крок вибору — це де стається перенавантаження, і місткість має йому передувати.

Друга прогалина — критерії приймання. Команди швидко проходять планування й мають намір написати критерії пізніше. Пізніше не стається на тому ж рівні конкретики. Людина, яка написала б точний критерій у кімнаті, наступного дня пише щось розпливчастіше з пам'яті або не пише його взагалі. Суперечки посеред спринту про те, що означає «завершено», майже завжди прослідковуються до пропущених критеріїв приймання на плануванні.

Накопичувана ціна цих прогалин — перевантажені спринти, відкриття посеред спринту, переграні визначення — чітко проявляється, коли ви її підсумовуєте: Податок на наради.

Чому нотатки планування спринту складніші, ніж здається

Планування спринту генерує більше інформації, ніж майже будь-яка інша регулярна нарада: мета спринту, числа місткості, обґрунтування вибору кожного елемента, критерії приймання по кожному тикету, відповідальні за залежності, елементи ризиків. Написання корисного підсумку вимагає захопити все це у формі, що буде корисною за три дні, коли хтось спитає «чому ми вирізали той елемент?».

Pavleur генерує звіт по плануванню спринту автоматично наприкінці дзвінка. Він захоплює мету спринту, вибраний беклог з обґрунтуванням, критерії приймання в озвученому вигляді й відповідальних за залежності в названому вигляді. Якщо хтось показував на екрані беклог чи таблицю місткості, цей візуал включено у звіт поряд з обговоренням — контекст, який суто аудіоінструменти на кшталт Otter чи Fireflies повністю оминули б. Будь-хто, хто приєднався пізно чи має перевірити рішення посеред спринту, має повний запис. Порівняння того, чим це відрізняється від суто аудіоінструментів: Pavleur проти альтернатив.

Обробка зміни плану посеред спринту

План спринту — це зобов'язання, а не контракт. Коли щось посеред спринту справді анулює план — інцидент на проді, критична залежність, що блокує три тикети, зсув пріоритетів від керівництва — правильна реакція — це швидкий дзвінок із переплануванням, а не тихе відкидання скоупу. Дзвінок із переплануванням займає 20 хвилин і продукує оновлену мету спринту, що відображає реальність. Альтернатива — спринт, що провалюється на папері, але неформально скоригований у спосіб, який ніхто не записав, роблячи ретроспективу важчою, а числа швидкості беззмістовними.

Виробіть звичку явного перепланування. Використовуйте ту саму структуру: оновлена місткість, переглянутий вибір, переозвучена мета. Це займає набагато менше часу, ніж плутанина, якій воно запобігає.