Sprint Planning: Формулиране на силна Sprint Goal
Научете как да дефинирате смислена Sprint Goal по време на Sprint Planning. Преместете фокуса от предаването на списък със задачи към осигуряването на реална, измерима стойност за клиентите.
Повечето Scrum екипи подхождат към Sprint Planning наопаки. Те взимат група от Product Backlog елементи в своя Sprint Backlog, сумират точките за сложност, за да достигнат обичайната си скорост, а след това се опитват да измислят изречение, което да обедини десет несвързани задачи. Scrum Guide от 2020 г. определя първата тема на Sprint Planning така: Защо този Sprint е ценен? Когато прескочите този въпрос или отговорите на него накрая, превръщате екипа си във фабрика за функционалности. Силната Sprint Goal дава на екипа една обща цел, гъвкавост в обхвата и ясна причина за сътрудничество.
Разликата между свършена работа и реален резултат
Слабата цел описва количеството свършена работа. Тя звучи по следния начин: Завършете потребителски истории 101, 102 и 104. Ако пропуснете история 104 поради прекъсване на външна услуга, целта се счита за неуспешна, дори истории 101 и 102 да решават основния проблем на потребителя. Още по-лошо, завършването и на трите задачи не означава нищо, ако клиентите всъщност не могат да постигнат това, което искат.
Силната цел описва постигнат резултат или промяна в състоянието на системата. Например: Да се позволи на клиентите при завършване на поръчка да плащат с дигитални портфейли, за да се намали процентът на изоставените колички. Сега Developers имат ясна цел. Ако проблем с интеграцията направи единия планиран доставчик на плащания неизползваем през тази седмица, те могат да го заменят с друг, без да провалят целия Sprint. Ангажиментът е към самата Sprint Goal, а не към твърд и неизменен план.
Започнете с първата тема
Scrum Guide очертава три отделни теми за Sprint Planning: Защо този Sprint е ценен? Какво може да бъде завършено през този Sprint? Как ще бъде свършена избраната работа? Ако следвате този ред, формулирането на целта става съвсем лесно.
Product Owner идва с идея, произтичаща от Product Goal. Той предлага защо този Sprint е важен за продукта. След това Scrum Team си сътрудничи, за да дефинира Sprint Goal, преди да избере конкретни елементи. Когато екипите започват директно от отделните задачи, те неизбежно стигат до изкуствено слепени цели като Франкенщайн, съшити с множество съюзи.
Признаци на крехка Sprint Goal
Можете да оцените състоянието на своята Sprint Goal, като зададете няколко прости въпроса по време на планирането:
- Съдържа ли целта думата „и“ три пъти, за да съшие несвързани проекти?
- Може ли целта да се счита за провалена, дори ако сте доставили нещо работещо и полезно на реалните потребители?
- Оставя ли целта нулев шанс на Developers да договорят обхвата при поява на неочаквани технически проблеми?
- Бихa ли разбрали клиент или висш мениджър защо си струва тази цел да бъде финансирана?
Ако целта ви прилича на списък за пазаруване, вие нямате цел. Имате график с маршрут. Всеки маршрут се проваля в момента, в който задръстването ви забави.
Справяне с разнородни задачи и поддръжка
Често срещано възражение е, че някои екипи поддържат множество наследени системи или прекарват половината си време в отстраняване на дефекти. Как могат да формулират една единствена цел? Ако екипът ви има десет напълно несвързани задачи, насилственото измисляне на изкуствена цел като „подобряване на стабилността на всички приложения“ е по-лошо от безполезно. Това поражда цинизъм.
В такива ситуации фокусирайте целта върху най-критичния очакван резултат за този Sprint. Отделете реалистична част от капацитета си за тази конкретна цел и приемете, че останалият капацитет отива за текуща поддръжка. Sprint Goal представлява основната посока, в която искате да постигнете реален напредък. Ако възникнат спешни инциденти в продукционна среда, екипът знае какво може да жертва първо и какво трябва да защити на всяка цена.
Ежедневен ориентир и истинска гъвкавост
Sprint Goal не е артефакт, който да бъде забравен до следващия Sprint Review. Тя е компасът за Daily Scrum. Developers оценяват напредъка си към Sprint Goal всеки ден. Ако напредъкът изостава, те адаптират плана. Могат да отпаднат Product Backlog елементи с по-нисък приоритет, като същевременно целта се запазва непокътната.
Именно тук се крие истинската гъвкавост. Тя не се изразява в способността да завършите шейсет точки по график. Гъвкавостта е способността да адаптирате детайлите по изпълнението, докато запазвате категоричен фокус върху създаването на стойност за клиентите.