Що робити з оцінкою неповної історії?

Я є частиною відносно нової команди розробників Scrum, припустимо, що наприкінці спринту кілька великих історій були in progressабо були acceptedPO.

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

Якщо так, чи варто їх переоцінювати? На мою думку, робота над цими історіями користувачів може бути мінімальною чи багато? Якщо ні, то чому б і ні?

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

agile scrum

— їстівний код
джерело

Я працюю з процесом XP і цікавився, який найкращий спосіб впоратися з подібною ситуацією

— chrisbunney

Невизначення перешкоди як можливого ризику та визначення впливу ризику RE (вплив * ймовірність) вказує на проблему з оцінкою. Історія користувача з високим рівнем РЕ повинна мати більший буфер витрат і часу, пов'язаних з нею для вирішення цих ризиків, якщо вони перетворюються на проблеми.

— Томас Оуенс

подвоїти його та додати 32, як і C => F

— Пол

Відповіді:

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

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

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

Якщо так, чи варто їх переоцінювати? На мою думку, робота над цими історіями користувачів може бути мінімальною чи багато? Якщо ні, то чому б і ні?

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

— Томас Оуенс
джерело

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

— їстівний код

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

— Томас Оуенс

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

— Томас Оуенс

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

— Девід Торнлі

@DavidThornley Це зовсім не спосіб управління ризиком, а відправна точка для плану управління ризиками, яка також включатиме стратегії виявлення та пом'якшення. Це техніка, яка використовується для того, щоб у вас було достатньо грошей та часу у вашому плані, якщо ризики перетворюються на проблеми. Він виступав Стів Макконнелл в Software Оцінка і Карл Уііджерс в цій статті . Важливо усвідомити, що це не буфер для виконання завдань, а проектний (або ітераційний) буфер, якщо різні ризики матимуться.

— Томас Оуенс

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

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

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

— Спустошена планета
джерело

Нітпік: Рішення, що робити з неповною історією, - питання пріорізації. Тому я вважаю, що власник продукту повинен вирішити це, а не майстер Scrum.

— sleske

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

— Спустошена планета

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

— Робін Грін

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

— Спустошена планета