Огляд спринту – один з найскладніших елементів в управлінні розробкою продукту по cкраму.
Коли я починав як скрам-майстер, то не надавав великого значення цій практиці. Тому протягом перших трьох років всі мої огляди спринту були обмежені лише формальною демонстрацією результатів роботи одній людині – власнику продукту.
Через деякий час я прочитав Scrum Guide, і я був просто спантеличений: як виявилося, я не розумів мети цієї зустрічі. З того часу огляд спринту це не просто обов’язковий елемент, а і якісно новий, де присутність клієнтів обов’язкова, збір зворотного зв’язку є обов’язковим, готовий інкремент на стабільному середовищі обов’язково.
8 кроків Sprint Review
Чи знаєте ви, що Scrum Guide описує принаймні 8 кроків для фасилітації цієї зустрічі? Мені здавалося, що всі ці кроки просто нереально вписати у двогодинну сесію, яка проходить між скрам-командою і групою стейкхолдерів. Ось чому я придумав Sprint Review Canvas, інструмент, який допоможе вам провести огляд спринту саме так, як він задуманий в скрамі. І я зробив це!
Структура Sprint Review Canvas
Огляд спринту реалізує щонайменше три принципи: співпраця, інспекція та адаптація. Кроки, позначені синім кольором допоможуть об’єднати всіх учасників, що важливо для розбудови довіри. Кроки, які призначені для перевірки інкременту і беклогу продукту позначені зеленим кольором. Кроки жовтого кольору належать до адаптації плану розробки продукту. Адаптаційний блок є найціннішим, бо між учасниками Sprint Review з’явиться прозорість і розуміння.
Фасилітація Sprint Review з Sprint Review Canvas
Учасники
Зустріч починається з того, що учасники створюють картки зі своїм ім’ям та роллю. Це легко здійснити онлайн, якщо ви використовуєте Mural або Міро.
Для огляду спринту, я б рекомендував, щоб власник продукту запрошують більше людей, зацікавлених у роботі команди. Чим більше “фан-база” у команди, тим краще. Для мене довгий час було незрозуміло, чому “Манчестер Юнайтед”, займаючи шосте місце в сезоні, і не потрапляючи в Лігу Чемпіонів, показує кращий фінансовий результат серед всіх команд у Прем’єр-лізі?
Ті команди, що поєднані з великою кількістю стейкхолдерів, будуть більш успішними, навіть якщо на якомусь етапі результати виглядають так собі. Успішна фасилітація вимагає різноманітних людей з різними поглядами. Тому, як початкова точка, я рекомендую принцип паритетності: в команді з восьми осіб запросити вісім стейкхолдерів, які також можуть бути представлені реальними користувачами.
Беклог Продукту
Власник продукту або скрам-майстер перед початком зустрічі може додати на канвас картки з історіями, які виконані відповідно до критеріїв готовності. Під час зустрічі, власник продукту дуже коротко пояснює стейкхолдерам, що є цікавенького в новому інкременті продукту.
Голос команди
Команда розробників може підготувати до початку зустрічі картки, які має сенс підсвітити стейкхолдерам як труднощі та перемоги. Наприклад, у команді впроваджена автоматизація тестування. Так, це не буде показуватися у вигляді цінного інкременту продукту, але чому б не розповісти зацікавленим сторонам про цю перемогу, навіть якщо вони мають мало розуміння всіх деталей? Описати, як автоматизація допоможе команді в подальшому розвитку. Якщо фасилітатор допомагає команді підкреслити такі речі чітко і коротко, то це сприятиме створенню довіри.
Демонстрація
Для глибшої демонстрації, я б змішав команду розробників зі стейкхолдерами та розбив їх на невеликі підгрупи з чотирьох людей. У таких невеликих групах розробники менше стресуватимуть, щоб провести гарну демонстрацію. Власник продукту і скрам-майстер не входять до цих груп, але якщо є питання, які в компетенції власника продукту, то стейкхолдери можуть залишити побажання або питання у вигляді карток на канві. Така динамічна демонстрація займає не більше 30 хвилин.
Беклог продукту
Після демонстрації власник продукту показує пріоритети для наступного спринту. Питання або побажання з попереднього етапу власник продукту має пояснити, як він бачить це з точки зору пріоритетів. Якщо є нові побажання, то вам потрібно описати вимоги, тобто адаптувати беклог продукту. На цьому кроці було б гарною ідеєю показати стейкхолдерам прогноз на наступний реліз за допомогою Release Burn-down Chart або будь-який інший відповідний інструмент.
Цінність інкременту
На цьому етапі фасилітатор може запропонувати стейкхолдерам попрацювати над інсайтами. Чи побачив хто нові можливості для продукту? Яка мінімальна робота потрібна для реалізації цих можливостей на ринку? Дуже часто продукт залишається недооціненим з боку користувачів, тільки тому, що мало було інформації. Я бачив чимало випадків, коли клієнти не використовують цінну функціональність, тому що відділ продажів не пояснив користувачам нові корисні функції.
Голос стейкхолерів
Створення цінного продукту – це головна мета скраму. І хто, як не стейкхолдери, можуть дати команді корисні рекомендації для наступного спринту. Звичайно, тільки власник продукту має вирішальний голос при встановленні пріоритетів, але будь-які поради, допоможуть власнику продукту приймати зважені рішення.
Результат зустрічі
Остання точка огляду спринту – оцінити інші аспекти, які потребують адаптації. Можливо, виявлені факти потребуватимуть адаптації бюджету, прогнозів, або ризиків. Фасилітатор може попросити учасників створити картки, що описують, що саме потребуватиме адаптації у світлі даних, які були згенеровані протягом всієї зустрічі.
Використання Sprint Canvas Review
Sprint Canvas Review прекрасно працює в контексті, коли у вас є достатньо стейкхолдерів. Якщо на зустрічі 1-2 стейкхолдери, то вся вправа буде спрощена до заповнення канви, а не живого обговорення. Ви можете спробувати протестувати цей підхід в спрінті перед релізом. Стейкхолдери завжди будуть мати більше мотивації брати участь, коли їм є на що подивитися. Ну а власнику продукту набагато простіше привести стейкхолдерів, коли за один спринт команда генерує більше цінності. Більше стейкхолдерів допоможуть вам зробити огляд спринту кориснішим, це буде надихати команду на збільшення доставлення цінності: чим більше цінності, тим більше зацікавлених сторін прийде на огляд спринту. Таким чином працює механізм для поліпшення продукту.
Слава Москаленко, CEO Agile.Live
Стаття була вперше опублікована на Scrum.org