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