Наші зустрічі зі планування спринту не тільки не веселі, вони прямо жахливі.

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

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

Як ми можемо зробити зустрічі більш приємними?

...

Ще кілька деталей у відповідь на запити про отримання додаткової інформації:

Чому елементи відставання не вставляються та не розставляються перед пріоритетним спринтерським завданням?

Історії користувачів дійсно мають пріоритет; ми не маємо уявлення, скільки часу вони займуть, поки ми не розбиємо їх на завдання! З (відмінних) відповідей тут я бачу, що, можливо, ми взагалі не повинні оцінювати завдання, а лише розповіді користувачів. Причина, по якій ми оцінюємо завдання (а не розповіді), полягає в тому, що ми отримували оцінки оповідань жахливо неправильно - але, мабуть, це тема зовсім іншого питання.

Чому розробники скаржаться?

1. Зустрічі тривалі.

2. Зустрічі одноманітні. Розповідь за сюжетом, завдання за завданням, бореться (так, бореться), щоб оцінити, скільки часу це займе і що це стосується.

3. Оцінка завдань робить оцінку користувача-історій безглуздою.

4. Чим довше зустріч, тим менше уваги в кімнаті. Чим менше цілеспрямовані колеги, тим довше проходить зустріч. Розвивається рекурсивна спіраль ненависті. Ми розглядали можливість розділити зустріч на два дні, щоб люди були зосереджені, але розробники не почули про це. Один день планування досить поганий; зараз у нас буде двоє ?!

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

Підводячи підсумки питання:

• Що ми робимо неправильно?

• Які додаткові способи зробити зустріч загалом приємнішою?

Зробити оцінку простіше

Розбийте планування спринту вниз.

Чи потрібно оцінювати окремі завдання? Я зробив планування спринту двома способами:

1. Розповіді оцінюються в сюжетних точках, а потім завдання оцінюються в години
2. Історії оцінюються в сюжетних точках, а завдання просто підпадають під це без оцінки

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

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

Оцініть в ідеальних одиницях

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

Я маю на увазі під собою те, що через деякий час, оцінивши їх в ідеальні дні, ви зрозумієте, що, можливо, потрібно в середньому зайвих 25% часу, який ви оцінюєте в середньому, щоб завершити історію. Скажімо, ви оцінили 4 ідеальні робочі дні, а замість цього вам знадобилось 5. З часом ви відстежуєте це, і тоді у вас є приблизне уявлення про перехід від ідеальних днів до реальних. Вашим першим інстинктом було б спробувати компенсувати це за рахунок надмірної оцінки, і ви, ймовірно, помилитесь. Тут головне - залишатися послідовними. Таким чином, ваше довгострокове середнє значення залишається незмінним. Звичайно, іноді це буде під іншим, а іноді і закінчиться, але чим більше ви оціните, тим краще вам станеться . Якщо ви виявите, що ви все ще не можете отримати гідну оцінку, можливо, це означає, що ви недостатньо знаєте історію, щоб правильно її оцінити.

Розмова про історії

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

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

Зробіть планування більш захоплюючим

Оцініть за допомогою Планування покеру

Наскільки зробити оцінку цікавішою, ви намагалися планувати покер ? Це те, що я завжди планував для всіх своїх спринтів на декілька команд, і це хороший спосіб утримати всіх учасників, оскільки кожна людина повинна хоча б вибрати САМО. Існує також велика кількість задоволення, коли всі в команді вибирають 3, а хтось ставить 20 і повинен пояснити себе, або коли всі в команді ставлять 5, але менеджер ставить 8 (хто буде сперечатися з начальник, коли він хоче приділити вам більше часу!).

Для цього все, що вам потрібно, - це кілька покерних карт для планування , які ми часто робимо на зворотному боці індексних карт, або використовуючи звичайні ігрові карти зі значеннями, прикріпленими до лицьових карт. Нічого фантазії, і це тримає всіх зосередженими. Пам'ятайте лише, що спроба виконати будь-яке завдання на цілий день (включаючи планування покеру) спричиняє велику продуктивність. Багато наборів карток поставляються з кавовою карткою не просто так; якщо хтось почувається згорілим, дайте команді перерву, щоб перезарядитись і забрати її, коли всі свіжі!

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

1. Чому елементи відставання не вставляються та не розставляються перед пріоритетним спринтерським завданням? Втрачати час розробників - це не цікаво. Нехай ваша команда веде роботу з власником продукту та менеджером проекту за кілька днів до того, щоб розставити пріоритети. Це стосується планування того, хто також є в кожній команді спринту.

2. Чому потрібен день, щоб розбити речі на завдання? Якщо у вас є команда з досить великим розміром (2-4 розробники, .5-1.5 QA людей на розробника, 1-2 різне), тоді у вас повинен бути 2-4 історії користувача цього спринту. Витратьте 30 хвилин або близько того, щоб власник продукту уточнив вимоги, а потім 30 хвилин або близько, розбивши його на ~ 8 годин завдань. Не вводьте завдання під час зустрічі. Просто погодьтесь як команда, яких завдань достатньо, щоб розумні люди зрозуміли їх, хто за них відповідає і про те, скільки часу вони повинні зайняти. Погодьтеся, що "скільки часу вони повинні тривати (включаючи тестування)" зручно вписується в спринт.

3. Якщо ви не просто розбиваєте речі на завдання, чим ще займаєтесь? Звичайно, ретроспектива може зайняти 30-60 хвилин, але буде коротшою, коли команди потраплять у паз.

Отже, підсумовуючи - киньте витрачати час на людей, і вони бояться зустрічей трохи менше. Крім того, розваги та товариські стосунки в колективі - це не те, на що можна звернутись на зустрічах. Ходіть разом на обід, жартуйте навколо, змішуйте людей, щоб мати кращі пристосування до особистості, проводити змагання з зростаючими вусами ... як тільки буде складено мораль, люди, природно, зроблять спринтські плани планування зустрічей більш легкими.

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

Кілька успішних ідей, які я або пробував особисто, або чув від інших команд:

• Робіть створення та визначення пріоритетів для користувачів без усієї команди. Власник продукту та / або майстер scrum може впоратися з великою напруженою роботою і просто дозволити команді підправити її.
• Зробити відставання значно довше, ніж один спринт. Це може зайняти деякий час, але якщо ваш відставання буде досить довгим, планування зустрічей зводиться до створення невеликих виправлень або вирішення останніх подій у бізнесі.
• Проведіть оціночні зустрічі окремо від спринтерського планування. Якщо люди вважають, що зустрічі занадто довгі, немає причин не розділяти їх.
• Конкретно планується прорив порядку денного. Це корисно, якщо ви часто витрачаєте час на очікування повернення одного або двох членів команди.
• Перервіться в середині наради і призначте всіх розробити одну або дві історії користувача, а потім зустрічайтеся разом, щоб повідомити і досягти консенсусу.
• Переконайтеся, що ваша планова зустріч стосується того, що робити, а не як це зробити. Інженери дуже легко потрапляють в останню. Якщо вам потрібно, організуйте окремі зустрічі з дизайну, де ви обговорюєте як.
• Відокремте свої історії на розслідування та реалізацію. Планування зустрічей часто триває занадто довго, коли члени команди знають занадто мало про те, над чим вони працюватимуть, і намагаються розібратися в цьому під час зустрічі.
  Наприклад, скажіть, що вам потрібно було інтегруватися з API, з яким ваша команда не має досвіду. Замість того, щоб намагатися створювати кошториси та завдання під час зустрічі планування про щось, про що ви незрозумілі, складіть одну історію розслідування, щоб вивчити API, зробіть просту програму "привіт світ" та навчіть її команді. Тоді ви будете готові планувати фактичну роботу.
• Під час зустрічей слідкуйте за певними питаннями. Не просто "планування нудне", але такий рівень деталізації, як "ми проводимо багато часу, розмовляючи про незрозумілі вимоги, і ніхто, здається, не знає правильної відповіді". Потім обговоріть ці конкретні проблеми у вашій ретроспективі та задумайте про конкретні рішення. Розбийте свою проблему до тих пір, поки шматочки легко вирішити.

Ми проводимо планування спринту та ретроспективу одночасно, і це майже завжди робиться за 90 хвилин, але ми одна з швидших команд. Ми робимо велике довгострокове планування кожні 5 компаній, що займає 4-6 годин. Кожна команда різна, звичайно, але якщо ви витрачаєте цілий день на кожен спринт, є багато місця для вдосконалення.

Ваші сеанси планування занадто довгі!

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

У вашому конкретному випадку: чому ви оцінюєте завдання? Ви повинні оцінювати лише історії під час планування. Завдання можуть бути оцінені пізніше власниками конкретних завдань .

Спосіб, який працював для мене:

• Швидкий вступ до спринту PO
• Оцінка спроможності спринту
• Історії розбігаються і планують покер (таймбокс 5/10 хвилин за історію), поки не буде достатньо оцінених матеріалів для покриття спринту
• Офіційне зобов'язання / прогноз команди

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

На моїй попередній роботі весь перший день кожного спринту (ми їх там називали ітераціями) займався:

• Ретроспектива. Ми почали робити це в другій половині дня, але ми часто виявляли ретроспективу щодо спринту, а потім повертаємось до роботи, зав'язуючи останні вільні кінці роботи цього спринту, тому ми вважали, що краще переконатися в тому, що робота була позаду нас, перш ніж її ретроспективувати. Також здавалося логічним консолідувати всі зустрічі, що надходили під час процесу Scrum, щоб інші дні можна було запланувати та провести в більш ідеальних умовах. Зазвичай це займало 2 години.
• Спринт-планування. Відстань був оцінений під час зустрічі з планування етапу (яка могла бути цілим днем ​​як для розробників, так і для осіб, що займаються виробництвом), і вони визначили пріоритетним завданням ОП перед початком кожного спринту. Ми з'ясували, скільки днів у нас було для розробників (облік свят, вака і т.д.), схопили роботу, яку ми думали, що можемо виконати на вершині палі, і швидко переглянули вимоги користувачів (раніше перевірені нашими бакалаврами) для отримати більш повне розуміння того, що пов'язано з роботою, ніж ми отримали з простого огляду під час MPM. Зазвичай це займало ще 2 години.
• Планування завдань. Знаючи історії та критерії прийняття, ми розділили кожну історію на завдання розміру куса, розраховані на ідеальні години (витрачена година орієнтована виключно на те, щоб це завдання було виконано "без відволікань чи блокування"). Як наша калібрована шкала в кінцевому підсумку була калібрована, 5 - спринт для розробників, тож 1 може бути що завгодно, включаючи два дні розробника. З цієї причини практично все потрібно було розбити, щоб члени команди мали змогу продемонструвати прогрес на дошці scrum. Це був ще один 2-годинний блок, який мав декілька прибутків між цим та наступним пунктом.
• Контур AAT. Наші ОП та БА не були програмістами і не кодували. Виробничі організації ховалися за контрактом, передбачаючи, що вони поставлять вимоги у вигляді шаблону Word і будуть співпрацювати з БА, щоб вдосконалити їх у цій формі. БА розуміли код, але їх час був суто аналізом та остаточним тестуванням (що вимагало існування системи, щоб вони могли записати свої макроси в Selenium). Отже, щоб переконатися, що наш код відповідав би критеріям прийняття, коли він доходив до цього, нам довелося написати власні AAT, що моделюють дії тесту на прийняття «паперового». Ми зазвичай робили це в тій же схемі NUnit, яку ми використовували для тестування модулів та інтеграції (ми спробували FitNesse і не змогли відмовитись досить швидко). Це був решту нашого першого дня кожного спринту і продовжувався другий.

На моїй нинішній роботі ми все ще приймаємо процес Scrum, у нас не було загального планування команд, і багато з того, над чим ми працюємо, не мають строгих критеріїв прийняття. Таким чином, наше планування спринту - це стільки ж пояснення того, що передбачає кожна історія і що ми будемо називати зробленим, оскільки це зобов’язання захопити вершину X ідеальних годин роботи з вершини. Ми відмовляємося від цього - хоча б зараз - тому що ми є власною командою, і кожен з нас особисто працює з кінцевими користувачами нашого програмного забезпечення, щоб зібрати вимоги та дизайнерські рішення. Вже тоді планування спринту - це річ, яка проводиться вранці кожного другого понеділка, а вдень проводиться очищення будь-яких особистих дорожніх блоків, щоб можна було серйозно розпочати розвиток у вівторок.

Щоб насправді відповісти на питання ОП, а не протиставляти інші коментарі / відповіді, кажучи, що це не повинно зайняти так довго, є способи підійти до Agile оцінки, спринтного планування та ретроспектив, які є трохи цікавішими, ніж ви можете використовувати.

Зокрема, вирішення Ваших проблем:

• Зустрічі довгі - таймбокс їх. Кожна зустріч, будь то ретроспектива, планування спринту, розбиття завдань тощо, повинна мати певну мету та тему обговорення, і повинна бути максимально обмежена певним часом. Завдання майстра Scrum - утримувати ці зустрічі на тему та проходити, щоб досягти цілей часу.

• Зустрічі одноманітні - щось із цього буде; ви працюєте в шматки розміру з укусом, по одному, так що ви будете робити те саме і знову і знову. Допоможе тримати команду зосередженою та рухатись до досягнення мети зустрічі.

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

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

  Якщо ваші історії тривають один день або менше, то це зайве, але не всі шкали балів калібруються однаково; на моїй останній роботі 5 було два тижні розробника (тому що на початку у нас було багато епічних оцінок), які в лінійному масштабі склали крапку до 2-х днів розробника. Зважаючи на такий масштаб, практично все повинно бути розбито на завдання. У моїй новій компанії точка ближче до половини дня розробника, тому 1 або навіть 2 - це, безумовно, її власне завдання, і 3-8 є неясним щодо змушення команди розбити її на завдання.

• Існує порочний цикл, який займає більше часу, аби люди були менш зосередженими, тому потрібно більше часу. Робіть перерви, як і ви повинні бути при кодуванні. Кожні 30 хвилин витрачайте 5 хвилин, щоб розтягнути ноги, перегрупуватися тощо. Ви можете робити це десять хвилин щогодини, але не натискайте на міцний блок часу на зустріч набагато далі. Ваші хлопці, можливо, голодують або потребують більше кави, перерви у ванній кімнаті тощо. Не заперечуйте їх; якщо ви змусите їх смоктати це, ви знайдете їх розум блукає. Крім цього, як і раніше, допоможе тримати дискусії короткими, милими і суттєвими.

Зустріч планування спринту складається з 2 частин:

1. Вирішіть, що буде робити команда
2. Вирішіть, як це зробить команда.

Перша частина є відносно прямою вперед - виходячи з кількості сюжетних точок, які команда вважає, що вони можуть скористатися, зобов’язавшись виконати багато історій користувача у своєму пріоритетному порядку. Зроблено.

Друга частина - те, що розробникам насправді слід насолоджуватись - розробка історії та розробка рішення. Завдання випадають із цього. Отже, попросіть власника продукту або будь-якого МСП, який він надав, пояснити обрану історію. Тоді будь-який розробник захоче взяти на себе, почніть обговорення дизайну. Використовуйте білу дошку. Відмов ідеї навколо. Весело.

Ось і справді. Якщо дизайнерські зустрічі не є цікавими, то тут просто щось не так.

Так, я знаю, що це старе питання, але у мене є нова відповідь. : P

Розбийте зустріч.

Ми розділили нашу зустріч з планування спринту на 3 окремі міні-зустрічі

• Відставання по догляду
• Підбір історії
• Розбиття завдань

Ми робимо кожного в інший день, відразу після нашого щоденного Scrum - як тільки щоденник виконаний, ми переходимо безпосередньо до планувальної діяльності, і тоді ми звільняємось від (регулярних планових) зустрічей решту дня.

Так що, ми вирішили наше планування: -О

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

У нас, як і у вас, були проблеми з дійсно жахливими зустрічами з планування спринту. У нас були всі потрібні елементи, але все просто забралося назавжди і насправді виснажувалося душевно та емоційно, щоб пройти.

Потім я зрозумів цю думку, прочитавши цю статтю Business Insider на 5-хвилинній щоденній Pivotal про те, як розбити наші зустрічі на більш короткі сесії та робити їх на початку кожного дня.

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

Тому ми вирішили спробувати.
Ми розбили нашу 2-годинну зустріч на три 25-хвилинні сесії. (так, це нечітка математика, але всі вважали, що наші зустрічі занадто довгі, і хотіли це зробити, лише якщо ми заощадили час).

І це спрацювало! Ми робимо це вже близько 6 тижнів над двома окремими проектами (загалом 6 двотижневих спринтів), і це змінило світ.
Ми більш продуктивні. Ми економимо тону часу.
Ми отримуємо кращі результати. І ми більше не боялися наших планових зустрічей.

І якщо чесно, наш 25-хвилинний проміжок часу досить розпущений - деякі сеанси проходять дуже швидко, як-от 5-10 хвилин на деяких наших сесіях по догляду, а деякі тривають довго, як коли ми в кінцевому підсумку визначаємо нові історії або мусимо розбивати розповіді. та переоцінювати під час переговорів. В цілому, як правило, це становить не більше 1,5 годин на весь шебанг, і я думаю, що саме тому він працює так добре.

Про деталі .....

Відставання по догляду

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

Ми будемо переоцінювати історії, якщо потрібно - як, скажімо, ми щось оцінювали місяці тому і, зрозумівши, що насправді подібна історія відбулася, ми можемо погодитися на повторну оцінку. (ми , до речі, використовуємо точки , що не містять одиниць , і не оцінюємо завдання ).

Крім того, якщо ПП додав нові історії, які, на його думку, є першочерговими, настав час їх оцінити.

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

Ця зустріч, як правило, закінчується з деякими учасниками та довготривала з іншими. (особисто я думаю, що це чудовий показник запаху того, як працює ваш PO)

Підбір історії

Увімкніть Кріса Восса , прийшов час домовитися.

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

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

Завдання

Гаразд, тому я буду першим, хто сказав, що завдання були моєю НАЙКРАЩОЮ улюбленою частиною планування наших старих одноденних зустрічей.

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

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

Це одне, IMHO, є тотальним змінником ігор.

Збираючи все це разом.

Отже, ось як виглядає наш графік Sprint:

• Понеділок - Щоденний скрам -> Огляд спринту
• Вівторок - Щоденні скандали -> Затримка відходу
• Середа - Щоденний розбір -> Вибір історії
• Четвер - Щоденний скрам -> Завдання
• П'ятниця - Щоденний скрам -> ретроспектива

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

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

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

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

На це питання відповіли вичерпно, але потрібно лише одне, щоб воно працювало та було весело.

Дайте владу команді. - тобто змусити їх працювати над тим, що, на їхню думку, є найважливішим.