Формулиране на силна Sprint Goal по време на Sprint Planning
Научете как да създадете ясна и стойностна Sprint Goal по време на Sprint Planning. Разберете защо сплотените цели превъзхождат случайните списъци с функционалности и как да запазите фокуса.
Повечето сесии за Sprint Planning се провалят още в самото начало, защото екипите ги третират като инвентаризация. Хората изтеглят десет несвързани задачи от тракера, изчисляват капацитета до последния час и приключват срещата. Когато някой попита каква е Sprint Goal, Scrum Master се опитва набързо да сглоби три изречения, които да обхванат всяка отделна задача в Backlog. Това обезсмисля целия замисъл на Scrum.
Първата тема задава посоката
Ръководството за Scrum от 2020 г. разделя Sprint Planning на три отделни теми. Първата тема поставя прост въпрос: защо този Sprint е ценен? Преди да се изберат елементи или да се оцени техническото усилие, Product Owner предлага как продуктът може да увеличи своята стойност и полезност в предстоящия спринт. След това целият Scrum Team си сътрудничи, за да дефинира Sprint Goal, която обяснява на заинтересованите страни защо този спринт е важен.
Ако пропуснете този разговор, се озовавате със спринт, пълен със случайни задачи. Членовете на екипа работят изолирано по възложените им билети. Ако се появи непредвидена техническа пречка, никой не знае какво може да отпадне. В резултат на това хората работят извънредно или жертват качеството, за да добутат всеки отделен елемент до финалната линия.
Какво прави една цел силна
Силната Sprint Goal е единна, бизнес ориентирана и гъвкава. Тя описва краен резултат и въздействие, а не просто обем свършена работа. Когато целта е фокусирана върху крайния резултат, разработчиците имат възможност да предоговорят обхвата на отделните елементи с Product Owner според новите знания, придобити по време на спринта.
- Описва ясна промяна във възможностите на потребителите, като например да позволи на клиентите да плащат със запазени кредитни карти.
- Предоставя единен критерий за успех, който не зависи от завършването на всеки елемент от Backlog.
- Създава споделена отговорност между разработчиците вместо индивидуално притежание на задачите.
- Формулирана е в сбито изречение, което всеки външен за екипа участник може да разбере.
Слаби цели срещу силни цели
Помислете за разликата между списък със задачи и истинска цел. Слабата цел звучи така: завършване на потребителски истории 102, 104 и 108, поправка на дефекти в процеса на плащане и обновяване на схемите на базата данни. Това не дава никакви насоки при възникване на компромиси. Ако миграцията на базата данни отнеме два пъти повече време от очакваното, какво точно трябва да защити екипът?
Силната версия за същия спринт би могла да бъде: активиране на периодично таксуване на абонаменти за европейски клиенти. Сега екипът има яснота. Ако изграждането на персонализиран потребителски интерфейс за плащане се окаже твърде сложно, разработчиците могат да използват готова базова форма, за да постигнат целта. Конкретните задачи се променят, но основната цел остава непроменена.
Правилото за гъвкавост
Ръководството за Scrum прави изрично разграничение: Sprint Goal е ангажимент, но обхватът на работата не е. Докато работят през спринта, разработчиците неизбежно срещат неочаквана сложност. Когато това се случи, те не изоставят мълчаливо целта. Вместо това обсъждат ситуацията с Product Owner, за да коригират Sprint Backlog, без да компрометират Sprint Goal.
Ако целта е просто да се завършат всички планирани задачи, тази гъвкавост изчезва. Всеки пропуснат билет се равнява на провал. Истинската цел дава на разработчиците автономията да решат проблема по най-простия работещ начин, който се появи в процеса на изпълнение.
Водене на дискусията за целта
Започнете Sprint Planning с преглед на Product Goal и текущото състояние на продуктовия Increment. Product Owner трябва да представи бизнес цел или хипотеза за предстоящия спринт. Дайте пространство на разработчиците да задават въпроси относно тази цел. Попитайте: ако можехме да доставим само едно ценно подобрение през този спринт, кое трябваше да бъде то?
Формулирайте целта, преди да изтеглите всички поддържащи елементи. След като екипът постигне съгласие за формулировката, изберете само онези Backlog елементи, които пряко подкрепят тази цел. Всеки останал капацитет може да бъде запазен за рутинна поддръжка, но всички трябва да разберат, че Sprint Goal има предимство пред всичко останало.