Scrum - як перенести частково повну історію користувача до наступного спринту, не перекриваючи відставання

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

a) Налаштування кількості точок історії вниз, щоб відображати лише роботу, яка залишається для завершення Історії користувача. На жаль, це зіпсує звіт про реєстр продуктів.

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

в) Не турбуйтеся ні з а, ні і продовжуйте здогадуватися під час планування спринту, говорячи такі речі, як "Добре, що історія користувача може бути X-очками історії, але я знаю, що вона на 95% закінчена, тому я впевнений, що ми можемо це вмістити".

У моїй теперішній команді ми в).

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

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

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

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

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

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

Варіант С

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

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

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

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

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

Зважаючи на те, що історія користувача, яку ми передаємо, частково завершена, як ми правильно її оцінимо на наступному сеансі планування спринту?

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

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

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

Як і М. Кон у своїй книзі, я, як правило, віддаю перевагу сценарію «все або нічого». Зрештою, намагаючись оцінити, чи набрали ви 5 балів з 8-бальної історії, чи, можливо, лише 6 чи 7 просто закінчується ще однією грою на здогадки ... і не забувайте, що ви вже отримали початковий оцінити вихід. Напевно, краще просто скористатися найпростішим методом і отримати всі бали після того, як він справді був завершений.

Цитуючи М. Кон з його книги¹ (мій наголос):

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

¹ Швидка оцінка та планування , переоцінка частково завершених історій, стор.66

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

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

Об'єднані оцінки не повинні дорівнювати початковій оцінці ...

² Дітто, с.66

Кращою рекомендацією для команди є розбиття історій на досить малий розмір, щоб уникнути подібних проблем³:

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

³ Дітто, с.67

Сподіваюся, це допомагає.

Я здивований, що начебто на це немає прямої відповіді. Я очікував хор "варіант D, манекен"!

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

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

Далі ми зрозуміли, що правильне виконання планування спринту є важливим - це виключає варіант C.

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

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

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

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

Перше запитання, яке потрібно задати, - Що означає історія? Якщо ви визначите точку історії як "Скільки роботи закінчено", тоді будь-яка відповідь буде робити. Однак якщо ви визначите точку історії як "Скільки вартості передається бізнесу", тоді важливо не надавати кредити, поки історія не завершиться на 100%, приймається і передається 100%. Змінення точок історії після спринту на основі того, що було завершено, приховає лише справжню проблему: а) не було чіткого розуміння історії, б) історія була занадто грубо визначена, в) в історії не було вимірних критеріїв прийняття, d ) недостатньо глибоке розуміння завдань або залежностей для завершення розповіді; e) заниження зусиль для тестування історії; f) зняття занадто багато сюжетних точок або ж) ... вставте сюди свою причину ...

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