User stories: как писать, чтобы команда понимала задачу
Шаблон «Как [роль] я хочу [действие], чтобы [ценность]» знают, кажется, все. Его вписывают в Jira, подставляют слова в скобки и считают, что user story готова. Но потом на планировании разработчик спрашивает: «А что конкретно тут нужно сделать?» И выясняется, что история написана, а понимания нет.
Проблема редко в самом шаблоне. Он вполне рабочий, если за ним стоит реальное понимание того, зачем пользователю эта функциональность. Сложности начинаются, когда story пишут как формальное требование, а разговор о сути откладывают на потом.
Шаблон без контекста
В одной продуктовой команде крупного российского ритейлера backlog состоял из сотен аккуратно оформленных историй. Каждая по шаблону, с полями «приоритет» и «оценка». При этом на каждом планировании половина спринта уходила на уточнения, потому что за формулировкой «Как покупатель я хочу видеть рекомендации» скрывалось пять разных представлений о том, что такое рекомендации, где они показываются и на каких данных строятся.
Формат записи никогда не заменит разговора. Ron Jeffries когда-то описал модель трёх C для user stories: Card, Conversation, Confirmation. Карточка - это напоминание о том, что нужно обсудить, а вовсе не исчерпывающая спецификация. Если команда читает story и у неё нет вопросов, это скорее тревожный сигнал, чем признак хорошей проработки.
Что делает story полезной
Хорошая история помогает команде понять намерение. Почему пользователь вообще этого хочет? Что он делает до и после? Какую проблему решает? Когда эти вещи проговорены, формат записи уже вторичен.
Несколько практик, которые помогают на деле.
Acceptance criteria как общий язык. Критерии приёмки работают лучше всего, когда их формулируют совместно - продакт, разработчик, тестировщик. Это не список «галочек» для QA, а фиксация общего понимания. Если критерий нельзя проверить конкретным действием, вероятно, он слишком абстрактный.
Разговор до написания, а не после. Полезно обсудить историю с кем-то из команды ещё до того, как она попадёт в backlog. Даже пять минут разговора у доски снимают те неоднозначности, которые потом всплывут на планировании.
Разбиение по ценности, а не по слоям. Классическая ошибка - делить большую историю на «бэкенд», «фронтенд», «тесты». Пользователю безразлична архитектура. Разбивать лучше по сценариям использования, чтобы каждый кусок можно было показать и получить обратную связь.
Размер имеет значение
Большие story - это почти всегда проблема. Если историю невозможно завершить за один спринт, команда теряет ощущение прогресса, а product owner не может гибко перестраивать приоритеты. При этом слишком мелкие истории превращаются в список задач и теряют связь с пользовательской ценностью.
Хороший ориентир - история, которую можно обсудить за пять-десять минут и реализовать за два-три дня. Если обсуждение затягивается, скорее всего, внутри спрятано несколько разных историй.
Частая ловушка
Команды иногда начинают относиться к user stories как к контракту между продактом и разработкой. «Вот что написано, вот что сделаем». Это разрушает саму идею. Story - это приглашение к диалогу, инструмент совместного понимания. Если процесс построен так, что разговор не нужен, вероятно, стоит задуматься, почему.
В конечном счёте user story - это способ договориться. И качество этой договорённости зависит от того, насколько команда готова разговаривать, уточнять и проверять свои предположения.
Если хотите глубже разобраться в том, как строить продуктовый backlog и работать с приоритизацией, посмотрите программу Advanced Product Ownership. А для тех, кто хочет системно освоить agile-практики с нуля, есть Certified Agile Professional.