Як часто команда Scrum повинна виконувати свої зобов'язання щодо спринту? [зачинено]

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

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

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

Дякую.

Справа не стільки в тому, як часто команда повинна "виконувати свої обіцянки".
Це більше питання розслідування, чому у команди виникне проблема з виконанням своїх зобов’язань.

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

Невиконання спринтерських зобов'язань є симптомом; вам потрібно зацікавити першопричину.

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

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

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

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

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

Спринт-зобов’язання - це те, що ви повинні бути в змозі зберегти, беручи до уваги всі "нормальні зміни". Ви можете прочитати мою публікацію в блозі про основи спритного планування, якщо хочете дізнатися більше про те, що я маю на увазі під базовою варіацією. І як заявив Стефан , невиконання ваших зобов'язань є симптомом, а не хворобою.

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

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

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

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

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

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

Що важливіше - це довгострокова тенденція вашої швидкості. Якщо щотижня ви додаєте 15 точок історії до своєї швидкості, але лише досягаєте на 10 більше, ніж ви робили за тиждень раніше, це справді погано? Десь вони вважають це «цілями розтягування».