Скільки часу має тривати зустріч планування спринту?

З вашого досвіду, як довго триватиме зустріч із планування спринту (Scrum)? 8 годин? Або він повинен бути коротшим (лаконічним), і подальші дискусії слід планувати як частину спринту? Наші спринти тривають 10 днів.

Відповідно до посібника Scrum :

Спринт-планувальна зустріч розрахована на вісім годин на один місячний спринт. Для коротших спринтів подія пропорційно коротша. Наприклад, двотижневі спринти мають чотиригодинні зустрічі з планування спринту.

Це взагалі працює для мене.

Поки це потрібно тривати, не менше і не більше. Все інше не спритний.

Якщо у вас є команда з 2 - 3 розробників і ви робите 1 тиждень спринти що-небудь більше години, ймовірно, це дуже ефективно.

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

Для отримання потрібного досвіду потрібен досвід, і саме для цього потрібні ретроспективи, команда вирішує, яка занадто довга або занадто коротка.

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

SCRUM - це вдосконалення процесу в ітераціях настільки ж, як і про вдосконалення вашого коду в ітераціях.

Не формуйте свій бізнес навколо цього процесу. Процес підтримує ваш бізнес. У той момент, коли ти робиш процес заради себе, саме час дістати сокиру. З цією метою немає "правильного" шляху. Зустрічі повинні тривати лише до тих пір, поки ви щось досягаєте. Якщо це займе у вас 30 хвилин або 4 години, поки це працює, тоді йдіть з ним. Ігноруйте те, що говорить вам якась книга / блог / тренер, і робіть те, що підходить саме вам.

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

З Scrum Primer ( PDF ):

Удосконалення продукту

Одне з менш відомих, але цінних настанов у Scrum - це те, що п'ять-десять відсотків кожного спринту має бути присвячена Команді для уточнення (або «догляду») пробілу товарів. Сюди входить детальний аналіз вимог, розподіл великих предметів на більш дрібні, оцінка нових елементів та повторна оцінка існуючих. Scrum мовчить про те, як робиться ця робота, але часто застосовувана техніка - це цілеспрямована майстерня в кінці спринту, щоб власник команди та продукту міг присвятити себе цій роботі без перешкод. Для двотижневого спринту п’ять відсотків тривалості означає, що кожен Sprint працює на південній майстерні з уточнення відставання продуктів. Ця активність щодо уточнення не стосується елементів, вибраних для поточного спринту; це для предметів на майбутнє, швидше за все, у наступному одному або двох спринтах. З цією практикою планування спринту стає відносно простим, оскільки власник продукту та команда Scrum починають планування з чіткого, добре проаналізованого та ретельно оціненого набору елементів. Ознакою того, що цей семінар з доопрацювання не робиться (або він не робиться належним чином), є те, що планування спринту передбачає значні питання, відкриття чи плутанину і відчуває себе незавершеним; Потім планувальна робота часто переливається на сам спринт, що, як правило, не бажано.

Це означає, що ви можете зосередитися на плануванні під час планування, і це не займає весь день, і команда починає втрачати увагу і нудьгувати.

У Scrum, працюючи до 2-тижневих спринтів, планування спринту розраховане на 4 години, що робить його подією на півдня. Однією з причин відносно великої кількості часу є те, що команда розробників повинна вміти впевнено погоджуватися, що всі предмети, що потрапляють у відставання спринту, можуть бути доставлені, а це означає, що вони повинні знати деталі. Не рідкість, як частина плану спринту, коли команди вибиваються з місця зустрічей на певні періоди часу, щоб далі вивчити елементи та переконатися, що вони готові перейти до відставання спринту. (Це може допомогти сприймати спринтерське планування як подію, а не як зустріч.)

Використовуйте своє "Визначення готовності" та тривалість часу, що подія планування спринту дозволяє переконатися, що всі елементи відставання, що входять у спринт, є і здійсненими, і готовими . тобто їх можна зробити (повністю, згідно з "Визначенням Готово") у спринті, і є достатня кількість інформації, щоб команда могла це зробити прямо зараз.
Зверніть увагу, що ви, мабуть, не хочете робити це для ВСІХ предметів під час планування спринту, оскільки це може зайняти багато часу. Намагайтеся регулярно проводити догляд за відстані (поза плануванням спринту), де ви можете розбивати елементи відставання та оцінювати предмети, які ще не оцінені, використовуючи, наприклад, покер для планування. (Я виявив, що це може бути ефективною роботою над робочим вечерею з командою розробників, якщо у вас є розкіш доступності вашої команди під час вечері!)

Елементи з високим пріоритетом часто можуть бути додані до відставання продукту власником продукту безпосередньо перед плануванням спринту, і хоча рутинний догляд за відходами, як правило, може бути зроблений перед подією планування спринту, завжди будуть такі нові елементи, як це команді потрібно витратити час на розробку деталей та оцінку складності під час змагань зі планування спринту, отже, чому це може розтягнутися на 4 години протягом 10-денних / 2-тижневих спринтів.

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

Як кажуть люди, є причини, з якими ви можете змінити спосіб запуску Scrum, якщо процес не працює для вас ефективно. Scrum, однак, дуже добре продуманий і перевірений фреймворк для початку, тому я би переконався, що ваші міркування виправдані, перш ніж змінювати процес.

На зустрічі з планування спринту команда повинна визначити два набори речей:

А) Що буде розроблено командою під час цього спринту

Б) Як це буде розвиватися

Ця зустріч повинна бути розробленою за часом, до двох годин за кожен тиждень спринту, розподіляючи рівномірно для кожної частини (частина А та частина В) зустрічі.

Отже, для спринту 4 тижні ця зустріч повинна бути не довше 8 годин, до 4 години для частини A і до 4 годин для частини B.

Під час частини A команда розробників повинна оцінити швидкість команди, яку вони вважають, що вона матиме під час цього спринту. Вони також повинні оцінити історії пріоритетного користування та вибирати достатньо цих (вже оцінених) історій користувачів, щоб виконати відповідно до їх оціночної швидкості роботи в команді.

У частині B команда розробників обговорить, як розробити більш складні історії користувачів, вже вибрані для розробки. Швидше за все, команді розробників не вистачить часу, щоб обговорити, як розробити всі вибрані історії користувачів, тому команді доводиться вибирати найскладніші історії користувачів.

Під час спринту команда розробників має достатньо часу, щоб завершити цю дискусію.

Відповідно до посібника Scrum :

Scrum події

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