Ревю спринта что это
Как провести спринт-ревью и не облажаться
Mar 13, 2017 · 2 min read
Наши команды разработки работают по скраму. Три составляющие скрама — планирование, ежедневные пятиминутки и ревью. Расскажу как мы проводим ревью в Авиате.
Спринт-ревью — это встреча на которой мы показываем, что сделали за спринт. В моих командах спринт длится одну неделю.
Почему важно проводить ревью:
Планирование начинает от вопроса “Что надо сделать, чтобы на ревью мы показали новую итерацию продукта?”. Это помогает отсекать ненужные задачи и фокусироваться на цели.
2. Быстро получаем отзывы от коллег, а значит поправляем баги и улучшаем UX до релиза.
К а ждую неделю (ну почти) мы показываем продукт, который можно пощупать. Это не обязательно тестовая версия приложения или сверстанная страница. Мы иногда быстренько собираем прототип на invision, показываем на обеде и собираем обратную связь. На ранних этапах получаем замечанию по дизайну, предложения по улучшению.
3. Всегда в курсе что делают другие команды.
Мы ходим на чужие ревью и зовем коллег на свои. Иногда наша работа зависит от других и вместо того, чтобы постоянно спрашивать статус работ, мы ходим на ревью и там задаем вопросы.
Какие ошибки мы допускали при ревью:
На ранних стадиях притирки к скраму мы забывали проводить ревью, передвигали, потому что нам нечего было показать.
Решение: железно забить встречу в календаре и ни при каких обстоятельствах ее не сдвигать. Даже если мало сделали все равно собирать на полчаса и показывать что готово.
2. Не звали коллег из операционного отдела и бухгалтерии.
Потом нам это выходило боком — операторы не были в курсе обновлений и плохо консультировали клиентов, у бухгалтерии не сводились отчеты.
Решение: пишу письмо с приглашением на ревью операционному директору и главному бухгалтеру. Если они заняты, то отправляют своих ребят. И в голове уже отпечаталось, что если их не позвать, то потом будет очень плохо.
3. Пытались решить все замечания на ревью.
На каждой встрече мы получали около 10–20 пунктов на доработку. Потом на планировании записывали в задачи. Ошибка была в том, что мы хотели все сразу улучшить и получить похвалу.
Решение: записать все предложения от коллег. На следующий день сесть с командой и на трезвую голову отсортировать задачи, записать в бэклог, задать себе вопрос “а насколько критично делать сейчас или мы можем запуститься так?”. Продукт надо запускать когда вам немножно за него стыдно. Предложения от коллег решали на следующих спринтах.
Обзор Спринта | Sprint Review
Обзор Спринта (Sprint Review) – встреча в конце спринта, на которой Cкрам Команда показывает заинтересованным лицам Инкремент с целью получить обратную связь о проделанной работе. Полученная информация служит основанием для обсуждения следующих шагов по оптимизации ценности продукта.
Часто эту встречу воспринимают как формальный отчет команды перед заказчиками. На самом деле Обзор Спринта имеет скорее неформальный характер и нацелен на развитие доверия, сотрудничества и коллаборации между сторонами. Встреча помогает команде понять, в правильном ли направлении она движется.
Иногда Обзор Спринта путают с Демо. Однако Обзор Спринта это нечто большее. Демо ( демонстрация готового функционала) — это только часть данного мероприятия.
Проводит встречу Владелец Продукта при поддержке Команды Разработки. Скрам Мастер следит за тем, что мероприятие состоялось, и его цель достигнута.
В таблице ниже представлена информация о том, что мы инспектируем и адаптируем на Обзоре Спринта.
SH* (от англ. stakeholders) заинтересованные лица.
Давайте разберем каждый пункт более подробно.
Инспекция
Цель Спринта. Встречу открывает Владелец Продукта. В начале встречи он объявляет, достигнута Цель Спринта или нет. Иногда в ходе Спринта команда понимает, что для достижения цели нужно сделать другой скоуп работы, или цели можно достигнуть кардинально другим способом. Необходимо, чтобы команда понимала, что достижение цели важнее сделанной работы, и как результат скажется на конечном пользователе и компании в целом.
Инкремент. В этот момент как раз и происходит демонстрация готового функционала. В зависимости от контекста, этот процесс можно организовать различными способами.
Ситуация на рынке. Это также не обязательный пункт, однако такие обсуждения помогают вовремя подсветить возможности и риски.
Метрики. Это важная часть Обзора Спринта. Про основные продуктовые метрики в Agile вы можете почитать в нашей статье Метрики в Agile. Без метрик сложно оценить успех или неудачу от определенного решения или проделанной работы. Наличие продуктовых метрик обеспечивает прозрачность на уровне бизнеса.
Адаптация
Бэклог Продукта. Обязательной частью Обзора Спринта считается сбор обратной связи. По результатам в Бэклог Продукта могут быть внесены изменения.
Обратная связь от стейкхолдеров. Наличие обратной связи по окончании мероприятия является критерием его успешности. На основе этой обратной связи команда принимает решения и адаптируется. Например, может взять в работу на следующий Спринт правки, которые стейкхолдеры попросили их внести в показанный функционал.
Бизнес цели на ближайшие спринты. Хорошей практикой является просмотр Road Map продукта на Обзоре Спринта. По окончанию каждой итерации можно вносить в него изменения. Эта информация должна быть открытой для всех заинтересованных лиц. Также Владелец Продукта может поделиться «взглядом в будущее» и рассказать на чем команда будет фокусироваться в ближайшее время.
Формат Обзора Спринта. В конце мероприятия можно спросить понравился ли формат Обзора Спринта.
Даты релиза. Готовый Инкремент — это еще не функционал, доступный для конечного пользователя. Поэтому важно рассказать стейкхолдерам планируемые даты поставки.
Форматы Sprint Review
Презентация
Это классический вариант демонстрации инкремента. Команда показывает проделанную работу в формате презентации. Здесь заинтересованные лица выступают в качестве слушателей и задают вопросы. Данный способ считается наименее эффективным, потому что не всегда помогает удерживать внимание аудитории. Также важно отметить, что в процессе презентации должно быть живое демо продукта (не на слайдах). Если демо не происходит, то встречу уже нельзя назвать Sprint Review. В идеале Скрам Команда должна стремиться сократить до минимума или совсем не прибегать к слайдам, а показывать все вживую.
Выставка
Для демонстрации продукта организовывается несколько «станций», на каждой из которых присутствует член команды разработки, демонстрирующий определенный функционал инкремента. Приглашенные стейкхолдеры небольшими группами перемещаются от одной станции к другой, задают вопросы представителям команды и дают обратную связь по представленному функционалу. Скрам Мастер контролирует время и порядок перемещения групп по станциям.
Анкетирование
Всем участникам Sprint Review раздается анкета, в которой задаются такие вопросы как:
Какова вероятность того, что вы порекомендуете продукт, и почему?
Ваши эмоции после ознакомления, и почему? и т.д.
Вопросы могут быть разными – это зависит от специфики работы Скрам Команды
Каждый участник Обзора Спринта выражает свое мнение в формате ответа по четырем пунктам:
Delete: Что одно вы бы удалили из инкремента
Add: Что одно вы бы добавили в инкремент
Keep: Что одно вы бы сохранили в инкременте
Improve: Что одно вы бы улучшили в инкременте
Длительность: не больше 4 часов для Спринта в 1 месяц
Участники: Скрам Команда + Заинтересованные стороны (Stakeholders)
Sprint Review: Днище — Огнище
«Мы легли на дно, мы зажгли огни, во Вселенной только мы одни». Кажется, эту строчку из песни группы Сплин смело можно признать саундреком внедрения практики Sprint Review у нас в Dodo Pizza.
Disclaimer: в статье Антон описывает первую версию жизнеспособного sprint review. У нас уже есть более продвинутая, но о ней в следующих сериях.
Первая попытка запустить практику sprint review в Dodo Pizza с треском провалилась.
Может быть, вы подумаете, что практики скрама сети пиццерий вообще ни к чему. Однако, одно из главных преимуществ Dodo Pizza — это, как ни странно, собственная IT-система, которая управляет всеми процессами в 495 пиццериях сети в 12 странах мира.
Над этой системой сегодня работает 80+ разработчиков и аналитиков (а будет со временем — больше двухсот). Как быстрорастущий стартап, мы стремимся к предельной эффективности, поэтому используем у себя многие фреймворки «гибкой разработки»: Cкрам, LeSS, экстремальное программирование.
Но что же это за cкрам, спросите вы, без sprint review? И будете правы.
Как известно, sprint review задает ритм команде и мотивирует завершить работу к концу спринта. Что еще важнее, он помогает создавать ценный продукт, нужный бизнесу, а не просто делать задачки из бэклога. Так, во всяком случае, пишут в книжках.
Однако у нас такой подход почему-то не работал. Например, на одном из первых sprint review мы показывали франчайзи Dodo Pizza из Казахстана их новый сайт — dodopizza.kz. Обратная связь была вдохновляющая: партнеры говорили, что сайт выглядит шикарно, а на фоне конкурентов так вообще будет казаться шедевром.
Когда мы его выкатили, выяснилось, что в нем много чего не хватает. То есть время мы на sprint review потратили, а полезного фидбэка от партнеров на деле не получили.
В общем, вскоре мы такие обзоры спринта по-тихому прекратили.
Через несколько месяцев я решил попробовать снова. К тому моменту у нас было уже восемь команд, работающих над одним бэклогом в фреймворке LeSS. Мы старались следовать всем правилам Large Scale Scrum, и отсутствие sprint review было одним из нарушений.
Я заранее подготовился к тому, что сначала все будет плохо, и правильный формат нужно будет искать, действуя методом проб и ошибок. После каждого обзора я просил участников оценить мероприятие по шкале от 1 до 10 (Днище — Огнище). Сначала оценки были очень низкие, ближе к «днищу». Однако мы не сдавались, экспериментировали, и где-то через пару месяцев они стали смещаться к «Огнищу».
Вот что мы изменили
Делаем домашнюю работу
Мы поняли, что на подготовку надо тратить не меньше времени, чем на сам обзор спринта — а то и больше. Всё мероприятие занимает два часа, а готовлюсь я часа три. Надо ведь согласовать с командами цели, договориться с партнерами, менеджерами управляющей компании, сотрудниками пиццерий и другими гостями, забронировать переговорки, сделать афишу, найти фасилитаторов, проинструктировать, составить и нарисовать расписание, развесить флипчаты для сбора обратной связи и т.д. Без всего этого будет просто хаос.
Не показываем недоделанное
Переговорки вместо open space
Авторы LeSS рекомендуют проводить sprint review в форме «базара». Все команды должны показывать свою работу в одном большом помещении, а заинтересованные могут ходить по станциям, которые им интересны. Мы так пробовали несколько раз, получалось шумно и суетливо.
Экраны ноутбуков маленькие, на них ничего не видно, шум от соседних станций мешает сосредоточиться, а постоянное перемещение людей создает хаос. Поэтому теперь в конференц-зале все собираются только вначале и в конце. Основное действие происходит в переговорках, где каждая команда представляет свою работу. Там оборудование, большие экраны, можно комфортно посидеть, подключены удалённые участники и есть место для сбора обратной связи.
Переходы запрещены!
Поначалу у нас стейкхолдеры свободно перемещались между командами. Но это раздражало. Представьте, что вы начали что-то рассказывать и через десять минут к группе присоединяется новый человек и задаёт вопросы о том, о чём вы только что рассказывали.
Начинаете отвечать — остальные скучают. Игнорируете — человек огорчается. Поэтому мы решили запретить перемещения между группами. Выбрал интересующую тебя тему — сиди в переговорке двадцать минут до следующего перерыва.
Дорогие гости
Удаленные участники
Несложно проводить встречу, когда все в одном помещении. Но у нас много удалённых сотрудников в Сыктывкаре, Нижнем Новгороде, Казани и Горячем Ключе. Им тоже важно присутствовать.
Поначалу «удаленщики» жаловались на то, что им было плохо слышно и почти ничего не видно. Сейчас мы заботимся о них так же, как и об офлайн участниках. В чеклисте подготовки к sprint review есть пункты, напоминающие нам о необходимости проверить связь и настроить оборудование. Мы ведем трансляцию в Slack, а с недавнего времени мы стримим мероприятие на нашем youtube-канале Dodo Pizza.
Отказ от обратной связи
Когда стало казаться, что все хорошо и улучшать формат дальше некуда, мы задали себе вопрос: а не фигню ли мы делаем? Обзор спринта — это ведь достаточно дорогое мероприятие (если посмотреть на него цинично — с точки зрения количества участников, их зарплат и потраченных часов). Используем ли мы эти два часа максимально продуктивно? В итоге мы решили полностью отказаться от сбора обратной связи во время sprint review.
В формате такого мероприятия сделать это глубоко и качественно не получается (вспомним кейс с Казахстаном). К тому же большую часть значимых и качественных отзывов мы собираем еще во время спринта, привлекая всех заинтересованных, от внутренних заказчиков до пользователей… Вы удивитесь, даже в Scrum Guide не написано, что на sprint review нужно собирать обратную связь: «During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.» Команда и стейкхолдеры, а не пользователи. Взаимодействуют, а не собирают обратную связь. Совсем другой смысл.
Открываем «кухню»
Не все стейкхолдеры плотно погружены в процесс разработки. Но все хотят знать, что там происходит. Именно на эти цели мы и решили переориентировать обзор спринта.
Мы по-прежнему показываем проделанную работу, но кроме этого команды рассказывают историю, которая стоит за новыми фичами. Какая была цель? Что происходило во время спринта? Что нас отвлекало или мешало достичь цели? Какие мы предприняли меры, чтобы спасти цель? Это помогает: так менеджерам становится понятно, например, почему «спрятать звёздочками email клиента в чеке» — совсем непростая задача («полчаса работы программиста», как казалось менеджерам). И наоборот, такой диалог помогает разработчикам думать в терминах «заказчиков» и их проблем, а не в терминах конкретных решений, над которыми они трудятся.
Это, пожалуй, главное, что мы изменили в нашем подходе. Прогресс налицо, но как всегда, еще есть что улучшать. Эксперименты продолжаются.
Главное, что мы поняли: не нужно зацикливаться на форматах, предложенных в методичках по скраму. Нужно пробовать, ошибаться и экспериментировать. Нет универсальных решений — нужно искать те, которые сработают в вашей ситуации.
Поэтому хочу напоследок предупредить: не копируйте наш формат. Он хорошо работает у нас, потому что родился в результате множества экспериментов. Ищите свой подход — и у вас обязательно получится. Хуже точно не будет.
Скрам-мастеру о событиях: Sprint Review / Обзор Спринта (Демонстрация?)
Не статусная встреча, а неформальная.
На ней проводится демонстрация инкремента продукта для получения обратной связи и развития сотрудничества.
Зачем проводится?
С целью инспекции инкремента и, по необходимости, адаптации бэклога продукта — Обзор спринта предоставляет ценные данные для следующего планирования спринта.
Кто где когда сколько?
Кто отвечает за встречу?
Скрам-мастер заботится о том, чтобы встреча состоялась, а все участники понимали её цель. Скрам-мастер обучает всех участников укладываться в отведенное на событие время.
Какие результаты должны быть достигнуты?
Пересмотренный бэклог продукта. Он включает в себя элементы, которые могут войти в следующий спринт. При появлении новых бизнес-возможностей, Бэклог продукта тоже может быть изменен.
Как проводить?
Скрам-команда и заинтересованные лица во время Обзора Спринта совместно обсуждают, что было сделано за Спринт.
17-минутный обучающий мультфильм об Обзоре спринта (на английском с текстом):
Ключевые элементы обзора спринта
1. Владелец продукта объясняет, какие элементы бэклога готовы, а какие нет.
2. Команда разработки рассказывает о том, что получилось во время спринта, какие возникли проблемы и как они были решены.
3. Команда разработки демонстрирует готовую работу и отвечает на вопросы об инкременте.
4. Владелец продукта описывает текущее состояние бэклога продукта. При необходимости он прогнозирует возможные даты завершения разработки продукта, основываясь на текущих показателях прогресса.
5. Все присутствующие обсуждают, над чем стоит работать дальше — ценные данные для следующего планирования спринта:
— Проводится обзор, как изменения рынка или потенциальное использование продукта могли изменить то, что нужно сделать в первую очередь.
— Выполняется обзор сроков, бюджета, возможностей и позиций на рынке для будущих релизов или возможностей продукта.
Мини-справочник и руководство по Scrum
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?