Как написать пользовательскую историю

User story или пользовательская история — это небольшой текст в формате пожелания, который помогает выяснить, кто такой пользователь, что он хочет и какова его цель. Стори используются чаще в сфере разработки приложений, софтов, ПО или инструментов. Их основная функция в том, чтобы помочь команде разработчиков создать такое приложение, которое удовлетворит пожелания большинства пользователей. В статье подробнее поговорим про юзер стори, их структуру, а также дадим семь примеров для понимания.

---

Что такое пользовательские истории и их значение для разработки

Пользовательские истории — это номинальное требование от пользователя с описанием его конечной цели. То есть стори не являются технической документацией — это чаще неформальный или деловой текст, который понимает каждый человек в отделе. Сам текст оформляется на карточках и содержит основные тезисы — считается, что истории должны быть максимально краткими и понятными, чтобы никто не сидел над их расшифровкой долго.

Прежде чем рассказать о структуре юзер стори, важно понять, для чего они вообще нужны и по каким правилам работают. Отвечаем — многие топовые компании по разработке ПО, игр или приложений работают по методике Scrum, которая основывается на образе мышления Agile.

Scrum — это что-то из мира практики, то есть метод помогает усовершенствовать работу в отделе. Сама методика подразумевает, что нужно постоянно обучаться и подстраиваться под изменчивые процессы — причина в том, что задачи в мире разработчика постоянно меняются, порой на полностью противоположные. И нужно быть к этому готовым — методика Scrum и обучает, как к этому быть готовым.

Agile — это образ мышления, один из принципов которого и базируется на идее совершенствования и умения подстраиваться под изменения. По сути, чтобы понять принципы Agile наглядно и внедрить их в работу, можно начинать с внедрения Scrum в работу и в жизнь — это будет первым шагом перестроить свое мышление.

Agile-разработка в целом — это все этапы разработки по порядку. Каждый этап перетекает в другой, и так по кругу. Наглядно это выглядит так:

Scrum предполагает эмпирический подход к работе, когда с помощью определенных примеров человек обучается всему практическим путем. Поэтому у метода есть своя структура — она состоит из трех артефактов: бэклог продукта, бэклог спринта и инкремент.

Бэклог продукта — это по сути список задач, которые нужно выполнить за все время. Обычно такой список составляют менеджеры проектов или продуктов и включает в него буквально все актуальные задачи отдела.

Бэклог спринта — это более краткий список задач, которые нужно выполнить во время текущего спринта. Спринтами в разработке называют отрезки времени, в период которых нужно выполнить насущные задачи — обычно он длится до двух недель, но иногда его урезают до недели. Все насущные задачи во время спринта обычно и включают разбор и обработку пользовательских историй для улучшения продукта. Стори подбирают не хаотично — сначала определяют цель текущего спринта, затем подбирают пользовательские истории, которые отвечают такой же цели.

Инкремент — это уже готовый продукт по итогам каждого спринта, обычно он демонстрируется на митапах внутри команды.

По итогу можно сказать, что юзер стори — это по сути единица в большой системе работы над созданием, тестированием и подготовкой продукта. Хоть это всего лишь крошечная часть процесса, она имеет важное значение, так как помогает выяснять желания и цели целевой аудитории. То есть в перспективе — делать продукт совершенным.

---

Зачем нужны юзер стори

Пользовательские истории, как уже сказали, много значат для отдела разработки и выпуска удачного продукта. Поэтому их нужно создавать вдумчиво и кропотливо, но при этом понятно и просто. Разберем, насколько вообще важны юзер стори — для этого рассмотрим их преимущества.

Помогают сосредоточиться на пользователях — несмотря на наличие списков, которые включают все актуальные задачи команды, пользовательские истории помогают их уточнять и сосредотачивать именно на пользователях.

Улучшают сотрудничество и взаимодействие внутри команды — во время составления юзер стори, а также в процессе спринтов команда прилагает все свои общие усилия, что прийти к общей цели.

Побуждают творческое мышление — чтобы добиться цели пользователя, нужно применять различные методы работы. В этом плане себя может проявить каждый сотрудник — это серьезно развивает творческое и критическое мышление.

Увеличивают мотивацию — если команда все делает правильно и в итоге добивается хорошего результата, это мотивирует работать еще лучше и усерднее.

---

Структура пользовательской истории

Ценность юзер стори разобрали — теперь можно подробнее изучить, как они пишутся, и что собой представляет их структура.

Структура юзер стори едина для каждой — она состоит из трех частей:

• пользователь — каждая юзер стори составляется на основе мнений и пожеланий целевой аудитории, поэтому важно отметить, что именно это за пользователь;
• действие — здесь прописывают, что хочет сделать пользователь с помощью продукта или его функции;
• выгода/результат/цель — в этой точке отмечают, какая конечная цель у пользователя, то есть зачем ему совершать определенное действие.

Таким образом, структура приобретает следующий вид:

Как пользователь, я хочу действие, чтобы выгода/цель

Например, как покупатель, я хочу использовать на сайте магазина корзину, чтобы товары, которые я хочу купить, хранились в одном месте.

Или — как пассажир, я хочу видеть всех таксистов поблизости в приложении, чтобы выбрать более подходящий вариант.

Хватает пары фраз, чтобы написать такую карточку — в ней обозначают, кто целевой клиент, чего он хочет, и какую выгоду получает.

---

Принципы и шаги написания пользовательской истории

Чтобы написать хорошую историю, важно руководствоваться принципами и использовать основные шаги, которые чаще применяют в большинстве компаний.

Принципы написания юзер стори называют INVEST — их разработал опытный программист Билл Уэйк. Давайте изучим их — всего принципов шесть:

• I означает Independent (независимость) — истории должны быть осуществимы, вне зависимости от обстоятельств;
• N означает Negotiable (открытость) — история должна быть открытой для обсуждения, то есть простой и понятной каждому;
• V означает Valuable (ценность) — все заинтересованные люди должны получить ценность от выполнения истории — пользователи, разработчики, владельцы проекта;
• E означает Estimable (оценочность) — история должна подходить для обсуждения и ее оценки в дальнейшем;
• S означает Small (лаконичность) — история должна иметь небольшой размер, в идеале не превышать одного сложноподчиненного предложения с простыми составными частями;
• T означает Testable (тестируемость) — чтобы завершить историю, ее нужно сначала протестировать, и она должна подходить для тестирования.

Если руководствоваться этими принципами, получится учесть мелкие детали при написании стори. Но это не все, что используют при подготовке истории руководители проектов, — для ее написания мы собрали последовательность четких шагов. Давайте с ними ознакомимся.

---

Шаг №1: проверьте пользовательские потребности

Это привычный шаг для всех, кто создает продукты для пользователей, — составить портрет своей целевой аудитории. Обычно он включает серьезный анализ потребностей, места работы, целей в жизни. Но это потом — сначала нужно подготовить портрет целевого клиента. Портрет клиента — это частично вымышленный персонаж, который и является идеальным пользователем продукта. На этом этапе обычно выясняется, кто клиент, чем он занимается, сколько зарабатывает, его пол, наличие семьи и так далее.

Например, если магазину детских игрушек нужно выяснить, кто их целевая аудитория. Один сегмент — это стопроцентно мамы, у которых не так давно появился ребенок, они замужем, сидят в декрете и не имеют дохода. Список можно продолжать, чтобы сузить аудиторию, а также продумывать и другие сегменты — скажем, покупать игрушки могут и беременные девушки, которые только ждут рождения ребенка. И ситуация внутри семьи, как и потребности, будут несколько другими, чем у мамы с детьми.

Когда портрет продумали, можно идти и углубляться в анализ — здесь важно выяснить, с какими проблемами может сталкиваться пользователь, чем поможет продукт для решения этой проблемы. На этом этапе хорошо работают опросы и интервью — это помогает получить реальную информацию от целевой аудитории, а также улучшить ее портрет в целом.

---

Шаг №2: создайте эпики

Эпики — это по сути те же истории пользователей, но они включают несколько и содержат описание функционала приложения и его задач. Обычно эпики используют, чтобы не перегружать список с общими задачами. Когда приходит время создания юзер стори, то эпики дробят на эти истории.

Это может выглядеть как обычный список из историй пользователей:

«— как пользователь, я хочу яркую обложку приложения, чтобы не терять его из виду на рабочем столе;

— как пользователь, я хочу автоматический скроллинг видео, чтобы не тратить время на перелистывание;

— как пользователь, я хочу поделиться своим профилем через QR-код, чтобы не тратить свое и чужое время на ручной поиск профиля».

Впоследствии эпики разделяют на несколько карточек, чтобы работать над ними. Если бы это делали сразу, список задач бы увеличивался из-за большого количества актуальных историй. Это может сбивать с толку сотрудников.

---

Шаг №3: создавайте пользовательские истории на основе эпиков

Как уже сказали, на основе эпиков можно писать юзер стори, но это нужно делать правильно, с учетом потребностей отдельных пользователей. Это значит, что нужно выбрать определенный эпик, который соответствует цели спринта — например, это обновление в приложении и добавление в него новых фичей. Получается, нужно выбрать тот эпик, который включает все пользовательские пожелания относительно нововведений. Потом выбранный эпик дробится на юзер стори. Скажем, основная цель эпика была упростить способ загрузки и установки приложения на ПК в грядущем обновлении. Тогда стори будет включать мини-запросы пользователей по части загрузки — упростить процесс регистрации в приложении через авторизацию в Google или Facebook*, например.

Система составления стори наглядно будет выглядеть так:

---

Шаг №4: визуализация пользовательской истории

Чтобы было удобно обращаться к историям в любое время, их нужно правильно визуализировать. Обычно для этого используются многофункциональные инструменты по управлению проектом в команде. Так любой член команды может зайти в систему и посмотреть стори и любые пометки к ней от коллег.

Проще всего визуализировать через такие инструменты, где предусмотрено создание досок и карточек. Например, это может быть привычный всем Trello, за рубежом нередко используют Kanban.

---

Шаг №5: проверьте все истории по критериям приемлемости

Критерии или принципы для составления и использования историй мы обсудили выше, но список этих принципов — не догма. Можно вносить корректировки, использовать только часть или добавлять свои критерии. В любом случае важно, чтобы каждая история соответствовала критериям — была понятной, краткой и четкой, в ней присутствовала определенная цель, которой нужно добиться и так далее.

---

Рекомендации по написанию юзер стори

Чтобы быстрее пройти по всем этапам написания, можно использовать несколько рекомендаций — они касаются определения пользователя, а также его запроса.

Определяем, «кто» будет вашим пользователем: 

• В истории на первом месте пользователь, и вся работа ведется для определенной группы людей — не для выгоды разработчиков или менеджеров проекта. Поэтому нужно понимать, кому можно принести пользу с помощью данной истории — так проще выяснить, кто именно является целевой аудиторией.
• Пользователь — это не только человек вне компании. Продуктом могут пользоваться и штатные сотрудники — те же редакторы, администраторы или дизайнеры. Важно учитывать и их пожелания, чтобы захватить всю целевую аудиторию.
• Погрузитесь в контекст жизни пользователя — попробуйте понять, о чем думает пользователь, как он проводит свое время в сети или в приложениях, что ему может не нравится при работе в сети и так далее.

Определяем, «что» нужно пользователю:

• не важно, сколько пожеланий у клиента, потому что одна история — это одно действие. Никаких исключений;
• постоянно уточняйте — если пользователю не нравится работа в профиле, попытайтесь обозначить, что именно ему не нравится. Например, «я хочу быстрее регистрироваться», «я хочу, чтобы фото в профиле не обрезалось», «я хочу более вместительный раздел с биографией» и так далее;
• не уходите в детали, которые не известны пользователю — это касается технической стороны интерфейса. Пользователя не волнует техническая сторона, а только конечный результат работы этих технических инструментов — ему нужно, чтобы приложение быстрее грузилось, а не то, какие технические составляющие за это отвечают, и как оптимизировать их работу.

Напоследок: все этапы работы важно обсуждать в коллективе, поэтому после написания пользовательских историй нужен серьезный мозговой штурм — так каждый из отдела сможет высказать свои мысли по поводу истории.

---

7 примеров юзер стори и эпиков

Без примеров сложно разобраться в тонкостях, поэтому давайте разберем семь примеров эпиков и вытекающих из них пользовательских историй.

Пример №1: авторизация в кабинете сайта

Сначала начнем с составления эпика, его основная тема — как быстро авторизоваться в кабинете.

После уточнения темы можно накидывать варианты того, с чем возникли или могут возникнуть проблемы у пользователя:

• кто — как покупатель;
• что хочет — я хочу быстро зарегистрироваться через Google;
• зачем — чтобы быстрее перейти к покупкам.

Первая история есть — теперь можно добавить еще несколько, если в этом есть необходимость. Например, как клиент магазина для взрослых, я хочу не указывать личные данные при регистрации, чтобы сохранить свою конфиденциальность.

Следующий пункт каждого эпика — это пояснения к теме. Необязательно включать этот пункт, но для понимания контекста он необходим. Здесь нужно обозначить, с чего вообще решили, что пользователь сталкивается или может столкнуться с этой проблемой. Варианты могут быть такие:

• данные с сайта показывают, что большинство пользователей покидают его после открытия формы регистрации;
• опросы показали, что многие клиенты хотят сохранить свою конфиденциальность даже от владельцев магазина;
• судя по трафику конкурентов, у которых упрощенная форма регистрации без указания личных данных, их конверсия гораздо выше нашей.

К пояснениям можно приложить ссылки или скрины с ответами пользователей в опросе, например. И после этого можно переходить к финальному шагу — обозначить границы эпика. Обозначение границ помогает задать путь к решению проблемы для разработчиков и отдела в целом.

То есть в этом пункте нужно прямо и описать действия для решения проблемы:

• убрать из формы регистрации все поля, где требуется указывать личные данные — за исключением раздела с вариантами оплаты товаров, а также номера телефона и почты пользователя;
• добавить возможность авторизации через Google или Facebook;
• добавить к кнопке регистрации ссылку с текстом на политику конфиденциальности.

Так, эпик приобретет такой вид:

Соответственно те пункты, в которых говорится об истории пользователей, потом и берутся за основу для карточек пользовательских историй.

---

Пример №2: как сделать меню ресторана в приложении более интересным

Подробный пример с описанием всех шагов был выше — надеемся, что логика ясна.

Поэтому далее будем показывать только то, как выглядит финальный вариант эпика и историй:

---

Пример №3: создание приложения под интернет-магазин косметики

---

Пример №4: как повысить лояльность клиентов через раздел с отзывами

---

Пример №5: улучшить пользовательский интерфейс приложения

---

Пример №6: добавить плейлист в приложение, который можно пополнять через поиск

---

Пример №7: улучшить безопасность приложения банка

Вывод

User story — это эффективный инструмент для организации работы внутри IT-отдела. Но система может подойти для команд из любых сфер, в которых требуется решать много сложных задач быстро.

Главное не только выучить всю механику, — как составлять эпики, а потом истории —  но и войти в контекст вместе с командой: устраивать регулярные собрания по обсуждения всех историй, эпиков, целей и задач.

Для внедрения такой методики нужно хорошо освоить навык анализа аудитории, а также запомнить структуру историй и эпиков. Кроме того, необходимо обоюдное участие всей команды и ее заинтересованность, а еще софт, в котором можно будет визуализировать все задачи и истории.

*запрещенная в РФ организация

Анна Мининкова, менеджер мобильной аналитики в JetSmarter, написала колонку специально для Нетологии о том, как использовать пользовательские истории для разработки требований продукта.

Пользовательская история – это легковесный инструмент для документации пользовательских требований к разработке продукта. История описывает функциональность системы с точки зрения пользователя с определенной ролью и целью этой системы.

Как <роль/персона юзера> я <что-то хочу получить> <с такой-то целью>.

Часто команды задаются вопросом: зачем работать над документацией вообще, если можно просто создать задачи в трекере и сразу начать внедрять новый функционал?

Но основная задача любой документации — выявить и описать потребности пользователя, для которого разрабатывается продукт. Она создана не столько, чтобы описать всё, что должен делать продукт, сколько чтобы убедиться, что команда знает, зачем пользователю продукт и как именно он будет им пользоваться. Невнимание к этой разнице в целях очень часто приводит к тому, что продукт работает «как написано», но не приносит никакой пользовательской ценности.

И если формат традиционной нарративной функциональной спецификации позволяет легко потерять ценность за событие «по нажатию на кнопку X должно происходить событие Y», то формат пользовательской истории: «Как <роль/персона пользователь> я <что-то хочу получить> <с такой-то целью>», позволяет команде задуматься над этой ценностью на самом раннем этапе.

История — это не продукт размышлений одного бизнес-аналитика или менеджера, который, как мог, попытался зафиксировать всё множество особенностей продукта или функционала, который нужно спроектировать.

История — это результат обсуждения команды разработки и бизнес-пользователей, который фиксируется в максимально ненагруженной форме.

Обсуждения позволяют избавиться от ложного представления о том, зачем разрабатывается новый функционал и кто им будет пользоваться. Вдобавок к этому истории позволяют продумать тестирование и ограничения системы на ранней стадии разработки.

Пользовательская история включает в себя следующие элементы:

1. Текст истории.
2. Критерии приемки: как мы поймем, что история завершена.
3. Тестирование. В идеальном случае пользовательские истории служат еще и легковесной тестовой документацией, в которой фиксируются тест кейсы.
4. Технические заметки. Сюда часто попадает информация об ограничениях системы, к примеру, о необходимости поддерживать определенный формат данных.

Как писать пользовательские истории

В идеальном случае черновая пользовательская история должна быть написана внутренним или внешним бизнес-пользователем, который заказывает разработку нового продукта или функционала у команды, а после коллаборативно разбирается вместе с командой разработки.

Текст истории должен объяснять действия пользователя, его потребность и результат, на который он надеется.

Как <роль/персона юзера> я <что-то хочу получить> <с такой-то целью>.

Чтобы понять, хорошей ли получилась пользовательская история очень удобно использовать следующий чек-лист:

• Разработка этой истории относительно независима. Чем больше программных зависимостей и ограничений, тем сложнее будет спланировать разработку такой истории.
• Ценность. Финальная часть конструкции «я хочу что-то получить с такой-то целью» должна содержать цель, которую вся команда признает важной и осмысленной.
• История должна быть легко оцениваема. Если она слишком большая или слишком размытая, чтобы оценить, то ее стоит разбить на меньшие части.
• Разработка не должна занимать больше недели. Иначе ее придется дробить на составляющие.
• Критерии приемки должны быть довольно четкими, чтобы по ним можно было протестировать продукт.

Распространенные ошибки в пользовательских историях

История для пользователя

Пример: «Как пользователь я хочу управлять отображением спецпредложений, чтобы удалять неактуальные и устаревшие».

Что не так с этой историей? Все важные части, кажется, на месте, но присмотревшись ближе, мы не знаем, для кого мы проектируем эту историю. Возможно, наш пользователь — администратор системы, которому нужно премодерировать показ спецпредложений от рекламодателей? Или, возможно, он рекламодатель, которому нужно управлять показом спецпредложений в списке?

У этих пользователей будут совершенно разные ожидания от системы. Ошибка этой истории — невнимание к роли пользователя в ней.

История для разработчика

Пример: «Как разработчик я хочу перейти на программную библиотеку Х, чтобы у меня была последняя версия библиотеки Х»

Часто такие истории пишутся, чтобы объяснить, что нужно сделать в рамках технического долга и рефакторинга, и здесь уже команда выступает непосредственным заказчиком. Однако, убедить бизнес в необходимости такой истории будет очень сложно, ведь на словах она не создает никакой ценности для пользователя. Как же с ней быть, если задача действительно нужная и полезная?

Необходимо посмотреть на то, что делает библиотека Х для конечного пользователя продукта. К примеру, она позволяет быстрее создавать спецпредложения и убирает задержку после их создания. Тогда история может звучать так:

«Как рекламодатель я хочу, чтобы в системе не было задержек после создания спецпредложений, чтобы я мог быстрее работать с большим объемом спецпредложений».

Перепишите ее с пользовательской точки зрения: «Как рекламодатель я хочу, чтобы система позволяла создавать мне папки, чтобы я мог быстрее работать с большими списками объявлений»

Технические заметки к этой истории могут выглядеть следующим образом:

• «Отрефакторить механизм добавления спецпредложений».
• «Обновить версию библиотеки, отвечающей за анимации добавления спецпредложений».

При этом к такой истории гораздо проще написать критерии приемки:

• «Пользователь не должен видеть задержки после создания спецпредложения при нормальной скорости интернета».

Никакой бизнес-ценности для пользователя

Пример: «Как администратор системы я хочу чтобы у меня была возможность сортировать спецпредложения».

Вроде бы все на месте, кроме ценности для пользователя. Зачем администратору сортировать спецпредложения? Не понимая какая цель у сортировки, нельзя сформулировать и дальнейшие требования к ней, а история теряет смысл.

Практические советы по написанию пользовательских историй

• Выбирайте в пользу разбивки истории на мелкие составляющие вместо одной громоздкой.
• По возможности избегайте технического жаргона в историях — особенно если впоследствии вашим бизнес-пользователям нужно будет приоритезировать истории.
• Избегайте обсуждения конкретных UI элементов. История должна оставаться актуальной, даже если визуальная реализация меняется.
• Обязательно оценивайте усилия по разработке истории.
• История должна приводить к понятному и ценному результату.

Порочные практики

• Формализм

Иногда бизнес-пользователи из лучших побуждений пишут огромные подробные истории. В этом случае команда часто сдается и пропускает обсуждения, видя, что все нюансы «кажутся» освещенными. Как результат, часть требований теряется, ведь один человек редко может охватить абсолютно все детали.

• Отсутствие обсуждений

Без обсуждения истории с командой очень легко пропустить мелкие детали или создать неправильное представление о задаче. Лучше потратить время на старте, когда не написано ни строчки кода, чем спохватиться в середине проектирования.

• Перевес в пользу технических историй

Если при планировании вы видите, что у вас готовы только истории технического плана, то в итоге может получиться, что истории реализованы, а продуктовой ценности совсем мало. Желательно соблюдать баланс между техническими историям, которые часто делаются для внутренних пользователей системы и теми, которые создаются для конечных пользователей продукта.

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

Читать еще 

• 21 совет по созданию хорошего интерфейса
• И ещё 26 советов по созданию хорошего интерфейса
• Учебник по юзабилити: ключевая правда о UX

Обучение

• Бесплатный курс «Adobe Photoshop: основы для веб-дизайнера»
• Программа обучения «Проектирование интерфейсов: UX-дизайн от стратегии до тестирования»
• Программа обучения «Веб-дизайнер: эффективный сайт от идеи до реализации»

Что такое user story? Для чего она нужна? И как “рассказать” правильную историю?

Началось это еще лет эдак 8 назад, когда я учился в институте… Стоял прекрасный солнечный день, солнышко светило в окошко, а настроение приближающегося лета питало мои надежды на скорое завершение учебного дня. Так…стоп, не об этом история, попробуем еще раз.

Первое знакомство с маркетингом началось с того, что любой продукт, который мы создаем начинается с потребности. У каждого из нас есть разные потребности: кушать, ходить в туалет, красиво одеваться, получать социальное признание и не только. Под каждую из этих потребностей создаются продукты (товары, услуги), которые решают так называемую “внутреннюю боль”.

Чтобы понять, как лучше решить ту или иную “боль” вы должны представлять себе сценарий или ситуацию, в которой находится человек с определенной потребностью. Вот тут и появляется история пользователя.

User story (или история пользователя) – это метод описания продукта или функциональности через ситуацию из жизни реального пользователя. Простыми словами, ситуация, в которой будущий продукт или функциональность решает задачу конкретной целевой аудитории.

Изначально данный термин появился в гибких методологиях разработки. Метод ориентирован на конкретную пользу, которую принесет новый продукт или функциональность. Приоритезация задач строится по-принципу от наиболее к наименее полезным доработкам. Таким образом происходит процесс “наращивания полезности”.

Если раньше у вас был сервис, где просто можно было загрузить фото, которое увидят другие, то теперь появится возможность оставлять комментарии. Этот функционал несет дополнительную пользу для вашего основного продукта и самое главное для пользователя. Ведь, согласитесь, неплохо посмотреть фото своих друзей, да еще и комментарий оставить, не так ли?

Какие задачи решает user story

• описывает потребности пользователя/ей или типа пользователя/ей
• помогает разбить потребности на конкретные задачи для разработки
• оценивает ресурсы, которые потребуются на разработку
• позволяет лучше приоритезировать задачи в общем плане развития продукта (или roadmap)
• дает возможность другим участникам команды лучше понять контекст задачи
• является основой для проведения тестирования с реальными пользователями
• и многое другое

Список можно продолжать и продолжать, метод очень полезен и позволяет закрывать огромное кол-во задач. Хотел бы упомянуть, что применение не ограничивается лишь областью разработки. История пользователя, это скорее мышление, то есть возможность представить себя в контексте конкретной ситуации и прочувствовать реальную потребность конкретного человека.

Как писать user story

Существует незамысловатая формула, в которую нужно просто подставить необходимое в скобки.

Я как <тип пользователя>, хочу <действие>, потому что <причина>

По существу, чтобы заполнить форму, вам необходимо:

• определить тот тип пользователей, который вас интересует (как правило, это ваша целевая аудитория)
• понять те действия, которые нужны пользователям
• выяснить почему именно эти действия нужны

Конечно, user story вы можете сочинить и сами, но вот вопрос, зачем? Так как главная задача метода, это решить самые наболевшие проблемы, то для начала вам необходимо их определить,  а потом уже сформировать user story. Предлагаю небольшую схему того, как должна создаваться история пользователя.

Все начинается с исследований, вы изучаете свою целевую аудиторию и пытаетесь вытащить ее потребности. Как правило, это могут быть интервью, опросы, фокус группы и прочее. Очень важно в процессе сбора информации приоритезировать полученные потребности.

Если у вас останутся записи или какие-то пометки, то будет еще лучше. Вы сможете более детально описать историю пользователя. Когда история пользователя будет готова, придет время приоритезации. Скорее всего у вас накопятся несколько user story и все они лягут в общий план работ согласно приоритетам. Если говорить о части разработки, это могу быть версии или же итерации.

Давайте перейдем к конкретным примерам и поймем как же это работает.

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

Пример истории пользователя: эмоджи

Представим себе, что у нас есть некая социальная сеть, где пользователи обмениваются фотографиями, оставляют комментарии и всячески взаимодействуют друг с другом.

Понимаю, как тяжело это представить…

И вот все бы ничего, да видите вы, что время, которое проводят пользователя а вашей платформе, начинает сокращаться. Если раньше в среднем за день человек проводил у вас час, то сейчас это уже 52 минуты. “В чем дело?”, – подумаете вы. Проведете опрос, поговорите с пользователями, в конце концов спросите совет у друзей и тут станет понятно, что пользователям стало скучно, хочется чего-то новенького.

Вас посещает идея, что неплохо бы удивить их чем-нибудь. Вы формируете историю пользователя:

Я как пользователь социальных сетей, хочу чего-то новенького, так как мне скучно.

Поштурмили немного с командой и придумали эмоджи (смайлы или эмоциональные реакции). Докрутили немного user story:

Я как пользователь социальных сетей, хочу эмоджи, так как мне скучно.

Теперь у вас есть готовая основа для доработки своей соц.сети. Вы оцениваете ресурсы, которые понадобятся, чтобы запустить такую штуковину, прикидываете время и берете в работу.

Если историй много

Если история пользователя у вас не одна (а это скорее всего так), то вы расставляете приоритеты между ними и берете в работу “самую наболевшую” у пользователей, а после переходите к следующей. Таким образом на первом плане у вас стоит всегда интерес пользователя и каждая следующая функциональность выпущенная в релизе, будет востребована.

Все истории пользователи, как правило, помещаются на некие доски (физические или электронные), по которым идет планирование работ. Если говорить про гибкие методологии, то привязка может идти к релизам функционала. Вы сами определяете, какие задачи попадут в ближайший релиз, а какие уйдут в следующий. Вот как приблизительно могут выглядеть доски с историями пользователей.

Но, как всегда есть нюансы: на практике,  часто приходится выбирать между бизнес задачами и пользователем. Прекрасно, когда ты можешь создавать только то что нужно людям, вопрос лишь в том на какие средства? Поэтому очень важно не отключаться от реальности и балансировать между экономикой и потребностями пользователей.

Не забудьте про измерения

Вы приступили к написанию истории пользователя, которая должна решить чью-то “боль”. Но как понять, что “боль” решилась? Наверняка необходимо как-то оценить эффект от того, что вы сделаете? Вопрос: “Как?”. Для этого используйте критерии приемки.

Критерии приемки – показатели, которые будут подтверждать результат ваших трудов.

Вернемся к примеру с эмоджи: если вы считаете, что создание эмоджи, поможет сильнее увлечь пользователей социальной сети, то нужно как-то померить эффект. Мы можем измерить среднее время на сайте за день и посмотреть, увеличится ли оно и на сколько, после того, как мы запустим эти долгожданные смайлы.

Два основных вопроса для критериев приемки:

• Какие показатели будем измерять, чтобы померить эффект от новой фишки?
• Какие показатели считать успешными, а какие нет?

Маленький секрет

Будь то разработка на гибких методологиях или же маркетинговое исследование, в результате которого появились истории пользователя, вам обязательно потребуется тесный контакт с реальными пользователями. Команда, которая делает что-то для определенных людей, должна периодически общаться с этими людьми. Узнавайте у своих пользователей, правильно ли вы поняли их боль, делайте customer development и оттачивайте свой функционал до блеска. В противном случае, вы просто один раз снимите данные с пользователей, “запилите” что-то, а в итоге это будет никому не нужно.

Закругляемся

История пользователя, это один из мощнейших инструментов для создания нужного продукта. Используйте его в своих проектах, общайтесь с пользователями и будьте открыты для изменений. А главное запомните, много историй не бывает, хороших историй пользователя тем более 😉

Алексей А.

---

Читайте также:

• Менеджер по продукту: кто это
• Техническое задание

---

Интересный ролик от компании Under Armor, атмосферное и заряженное видео.

• Определение
• Общий шаблон
• Чем отличается от спецификации и юз-кейса
• Как написать юзер-стори
• Несколько практических советов
• Мнемоника: запомни слово INVEST
• Главное

Что это

User Story переводится с английского как «пользовательская история». Это общее описание функций программы, написанное как бы от имени пользователя. В user-story формулируется, чем функционал приложения ценен для заказчика. 

Само название — user story — указывает, что этот документ имеет формат истории и излагается в повествовательной форме.

Ключевой компонент гибкой разработки ПО — фокус на людях. Пользовательская история ставит конечных потребителей в центр всего процесса. В ней не используется технический язык, она должна лишь дать команде контекст. Прочитав user story, члены команды понимают, что именно и зачем они делают, и в чем ценность создаваемого им продукта.

Шаблон user story

Юзер стори пишется по шаблону «Как [пользователь], я хочу […], чтобы […]». В таком формате поясняется, что именно хочет пользователь или заказчик, и почему.

Рассмотрим этот шаблон подробнее.

• Пользователь — собирательное название. Если у вас много конечных пользователей, для каждого пишется отдельная юзер стори. Например, если ваш продукт — торговая онлайн-площадка, у вас как минимум будут  user story для покупателя и продавца.
• «Я хочу…» — в этой части описываются намерения и желания пользователей, то, чего они на самом деле хотят достичь, используя нашу программу. Стоит заострить внимание на том, что здесь не нужно описывать UI, речь идет не о функциях ПО, а о желаниях пользователя.
• «Чтобы…» — здесь поясняется, как желание из предыдущей части вписывается в общую картину, какую большую проблему нужно решить.

Отличие user story от спецификаций и сценариев использования

Текст  юзер стори поясняет роль и действия пользователя в приложении. Пользовательская история в чем-то заменяет спецификации требований и сценарии использования, но все же отличается от них. Различия небольшие, но существенные:

• user story — не подробное описание требований к приложению, а изложение намерений «в общем»
• пользовательская история недлинная и читабельная, она понятна всем людям, занятым в проекте
• в  юзер стори указывается ценная функциональность, которую можно реализовать за несколько дней или недель
• пользовательская история не громоздкая, она организована в списки, а их легко изменить при поступлении новой информации
• в начале проекта  user story не детализируется (это делается для ускорения процесса разработки)
• пользовательскую историю не нужно поддерживать, после реализации необходимость в ней отпадает.

Как писать user story?

Пользовательская история должна быть написана грамотным языком. 

Когда пишете user story, следует следить за тем, чтобы не скатиться в написание техзадания. Истории пользователей фиксируют только самые важные элементы требований:

1. Для кого это создается?
2. Что этот «кто-то» ожидает от системы?
3. Почему это важно?

Практические советы по написанию user story

• Лучше написать побольше небольших историй, чем несколько объемных.
• Писать user story  лучше всей командой, чтобы не пропустить важные для продукта, бизнеса и пользователей вещи.
• Пользовательскую историю нужно писать простым языком, без рабочего сленга (по возможности). Благодаря этому она будет понятна всем людям, занятым в проекте.
• Нужно точно описать потребности пользователя.
• Юзер стори нужно писать так, чтобы по ней можно было тестировать.
• Код пишется после тестов.
• В написании  user story не стоит жестко привязываться к каким-то элементам пользовательского интерфейса.
• В каждой истории должна быть оценка сложности реализации, а также времени, которое потребуется на реализацию.
• User story должна содержать описание конечного результата.
• Хорошая user story соответствует модели INVEST.

Модель INVEST

INVEST — слово, использующееся для запоминания критериев качественной истории:

• I – independent. История должна быть независима от других историй.
• N – negotiable. История обсуждаема, в ней отражается суть, а не детали или конкретные шаги по реализации.
• V – valuable. История представляет ценность для клиентов и бизнеса.
• E – estimable. Пригодность для оценки: историю можно оценить по сложности и трудозатратам.
• S – small. Хорошая история маленькая, ее можно реализовать за одну итерацию.
• T – testable. История имеет критерии приемки и ее можно протестировать.

Запоминаем

User story — максимально понятное описание функционала продукта, его особенностей и пользы для конечного пользователя. Польза  user story в том, что она помогает разработчику лучше понять продукт и целевую аудиторию заказчика. Для проверки качества истории используются INVEST-критерии.

Как правильно формулировать пользовательские истории? Третья статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.

На сегодняшний день разработка мобильных приложений перестала быть уделом только лишь умудренных опытом специалистов. Все чаще результат работы разработчика-самоучки становится намного интереснее и гораздо полезнее для конечного пользователя, о чем свидетельствует высокие рейтинги продуктов независимых программистов в сторах. Удачный выбор идеи все еще остается основополагающим фактором успеха приложения. Кроме того, в наше время создать успешное мобильное приложение может даже человек, весьма далекий от программирования, поскольку для этого существует аутсорсинг.

Процесс разработки мобильного приложения состоит из нескольких последовательных этапов. Первоначальным и в итоге во многом определяющим конечный результат является написание User Story.

Что такое User Story?

User Story в первую очередь — это руководство к действиям по созданию, оптимизации и продвижению продукта. Во-вторых, это возможность еще раз оценить перспективы продукта. В большом WEB и среди разработчиков ПО функции User Story успешно заменяют функциональные спецификации.

Три довода в пользу User Story по сравнению с спецификациями при разработке мобильного приложения:

1. Во время создания пользовательской истории разработчики продумывают, как решать ряд задач еще до стадии начала процесс разработки. User Story отлично помогает взглянуть на всю систему целиком.
2. Пользовательские истории являются результатом работы команды, в отличие от спецификаций. Обычно последние пишутся одним или несколькими людьми в команде. Как предмет коллективной работы, пользовательские истории помогают выявить все слабые стороны продукта и решить все проблемы в реализации идеи до разработки в формате живого общения.
3. User Stories создаются в том числе для тестировщиков. Они содержат пользовательские сценарии, которые станут основой тестирования после сдачи проекта.

Как было сказано выше, правильно написанная пользовательская история позволяет избежать множества распространенных проблем, главная из которых — неправильное представление конечного продукта разработчиком. Ситуация, кстати, достаточно распространенная. И в интересах издателя, чтобы результат разработки мобильного приложения полностью соответствовал требованиям и ожиданиям пользователя, а значит, созданию User Story следует уделить особое внимание.

Какие требования выдвигаются к написанию пользовательских историй?

В первую очередь необходимо, чтобы при написании пользовательской истории присутствовало максимальное количество заинтересованных людей. Написание хорошей User Story — коллективный труд, в котором важна командная работа, целью которой является продумывание всех нюансов. Этот тот самый случай, когда две головы лучше одной.

В случае создания мобильных приложений разработчик должен хорошо представлять основные требования, которые пользователь будет выдвигать к создаваемому приложению. На основе этих требований и следует формировать пользовательскую историю. Она должна вести виртуального пользователя по всем страницам приложения, решая на каждом этапе совершенно конкретную задачу. В итоге шаги трансформируются в разделы, а решения — в функционал.

Начинать User Story лучше всего с описания целевой аудитории. Самый важный момент на этой стадии — четкое обозначение ролей в приложении. Далее следует расписать каждую роль в зависимости от действий в приложении, которые приводят к определенному результату. Схема выглядит примерно так:

В качестве… (описание представителя ЦА, его роль в приложении), он получает… (действия в приложении) для… (цели его действий в приложении).

Без наличия хотя бы одной из описанных характеристик теряется пользовательская ценность истории, что в итоге может привести к разногласиям в момент приемки. Проработка всех возможных сценариев очень важна, поскольку такой подход позволяет избежать некоторых достаточно неприятных сюрпризов на последующих этапах создания мобильного приложения.

Окончательная формулировка истории должна быть лаконичной и точной. Если сформулированная заказчиком история содержит сложные расплывчатые понятия, ее следует переписать. В идеале User Story должна быть:

1. Внутренне независимой;
2. Структурно изменчивой;
3. Ценностно-ориентированной;
4. Учитывающей критерии оценки каждого этапа;
5. Оптимизированной по времени (рассчитанной на 1 неделю);
6. Проверяемой (легко оценимой в результате)

Рекомендации для написания правильных User Story

• Написание пользовательской истории – это своеобразный «мозговой штурм», который следует использовать с максимальной выгодой для продукта. Во время ее написания должны быть заданы все вопросы и получены все ответы. Менять что-то на стадии разработки и тем более после сдачи проекта крайне сложно и затратно.
• Вместо одной большой пользовательской истории лучше написать несколько более мелких и точных. Т.е. крупные и громоздкие истории необходимо фрагментировать с учетом конкретики задач, разбивать на более детализированные и мелкие.
• Оптимальный размер User Story (следует ли ее разбивать на под-этапы или же объединять несколько в одну) определяется просто: на разработку должно уходить от 0,5 до 4 «идеального дня». Если уходит больше четырех, то имеет смысл фрагментировать. Если меньше – надо объединять.
• Обязательно прописывайте в истории критерии приемки, поскольку при их наличии тестировать соответствие готового продукта и истории намного легче.
• Хотя в большинстве случаев формат пользовательской истории должен соответствовать основным требованиям, но в некоторых случаях, если, к примеру, речь идет о дизайне, можно ограничиться более свободным форматом в виде скетчей или набросков.
• Следующий совет может кого-то и удивит, но его практическая польза подтверждалась неоднократно. В процессе работы над созданием User Story желательно использовать небольшие бумажные карточки. При командной работе этот метод просто незаменим, поскольку способствует динамике процесса. Готовую пользовательскую историю также не следует убирать с глаз долой в недра ноутбука или письменного стола. Повесьте их на стену, это будет очередной мотиватор для выполнения поставленной задачи.

Что делать не стоит?

• Чрезмерно детализировать. Из-за слишком подробной, описанной в деталях User Story, процесс ее обсуждения командой может быть сведен к минимуму, что не всегда хорошо для поиска оптимального решения поставленной задачи. Всегда нужно оставлять место для творчества, а формальный подход с ним, как известно, несовместим.
• При всех соблазнах сделать это пропускать обсуждение ни в коем случае не стоит. Даже если, на первый взгляд, все совершенно очевидно. Именно в процессе обсуждения можно, как говорится, расставить все точки над і.
• Формат User Story не предполагает наличие технических задач.

Необходимо отметить, что User Story не является чем-то нерушимым и не приемлющим каких-либо изменений. В принципе, при необходимости заказчик может добавлять новые пользовательские истории, менять приоритеты и т.д. Это вполне допустимо. При этом разработчик со своей стороны обязан объяснить заказчику, чем чревато будет предложенное изменение или добавление. Живое общение на этой стадии — залог успеха в будущем. Ведь создание успешного мобильного приложения – это блестящая идея + не менее блестящее ее воплощение. А для последнего значение правильно написанной User Story вряд ли можно переоценить.

Мы посоветовались с экспертами в области мобильной разработки и выяснили, как с их точки зрения лучше работать с историей.

Анна Минникова, Гиперболоид, сертифицированный Scrum Professional, работала продакт и проджект менеджером в крупнейших геомобильных приложениях СНГ, сейчас занимается lean коучингом.

1. Как правильно написать User Story?

Командой. Причем команда обязательно должна включать в себя менеджера продукта/клиента/стейкхолдера или даже конечных пользователей вашего продукта. Пишите user story не для того, чтобы получить формальные «требования», а чтобы вытащить на свет все важные для вашего продукта, бизнеса и пользователей нюансы.

Обязательно формулируйте персоны вашего продукта до начала работы над user story. Это поможет вам лучше прочувствовать пользовательские нужды/боли/желания и лучше понять, для кого вы проектируете ваш продукт.

Ваша идеальная история должна быть написана по такому образцу:

Как, <роль пользователя>, я <что-то хочу получить>, <с такой-то целью>

Сейчас вы сформулировали бизнес-ценность для пользователя вашего продукта. Но прелесть пользовательской истории в том, что она формулирует не только бизнес-ценность, но и требования для разработки и тестирования. К этой простой формулировке вы можете добавить критерии приемки, технические заметки, описание обработки ошибок, которые суммируют все задачи, которые вам нужно сделать.

Вот как в укороченном виде выглядела пользовательская история в одном из моих проектов:

Как водитель с загоревшейся лампочкой бензина я хочу быстро найти ближайшую хорошую заправку, чтобы заправиться качественным бензином.

Критерии приемки:

1. Как водитель с загоревшейся лампочкой я могу просмотреть все ближайшие заправки.
2. Как … я могу выбрать заправки подходящих мне брендов АЗС.
3. Как … я могу видеть ближайшие заправки выбраннах брендов списком.
4. Как … я могу видеть ближайшие заправки выбранных на карте.

Обработка ошибок:

1. При выключенной геолокации пользователя необходимо дать ему информацию о том, где ее включить.

Технические заметки:

1. Заправки в списке должны обновляться при изменении местоположения пользователя на 100 метров.

Такая формулировка задачи помогает разработчикам и тестировщикам не пытаться сравнивать готовую задачу с ui требованиями, которые быстро устаревают, а смотреть на основные проблемы, которые должны быть решены в рамках задачи. Дополненная прототипами, такая история легко становится задачкой в джире или бейскемпе, которую можно делать даже без финального дизайна.

Вот как выглядели экраны, относящиеся к этой истории, в итоговом приложении:

2. Как объективно оценить ее полезность и востребованность?

Пользовательские истории полезны, если вы понимаете, что с написанием пользовательской истории для самого простого проекта вы ступили на тяжелый путь сомнений: «зачем мы делаем наш продукт»?, «точно ли нужна эта фича в продукте?», «да пользователей с такими потребностями днем с огнем не сыщешь», «кто будет пользоваться тем, что мы делаем?». Эти вопросы не очень приятны, но честные ответы на них помогут вам спроектировать лучший продукт.

3. Чего делать не стоит при работе с User Story?

Писать их в гордом одиночестве или поручать написать пользовательские истории, к примеру, менеджеру проекта. Если, конечно, вы не являетесь конечным core пользователем продукта, который вы разрабатываете

Также не очень здорово писать объемные, большие истории. Если ваша история не вмещается в стандартную итерацию вашей команды (я надеюсь, что это максимум 4 недели:), то она слишком велика и стоит задуматься, как можно ее поделить на несколько.

И самые главные грабли – писать пользовательские истории, которые пойдут в разработку, до того, как вы прошли через процесс customer development. Хорошо сделать это для общего понимания того, что пользователь, по вашему мнению, будет делать с продуктом.

Но пользовательские истории нужно писать не только для того, чтобы выразить ваше мнение о продукте или мнение заказчика. Они должны выражать мнение тех, кто будет покупать и пользоваться продуктом (не забудьте о том, что это не только конечные пользователи, но и те, кто оказывают влияние на совершение покупки. К примеру, конечными пользователями игр часто являются дети, но покупают их родители).

Поэтому для того, чтобы написать ценную и реалистичную пользовательскую историю, вам нужно получить максимум информации о ваших будущих пользователях:

• считают ли они проблему, которую решает ваш продукт, достаточно серьезной (к примеру, все игры решают серьезную проблему – убийство времени и побег от скуки);
• как они решают свои проблемы сейчас;
• какие заменители или конкуренты есть у вашего продукта;
• и еще массу важных моментов, которые стоит узнать до того, как вы написали гору кода :).

Это самый большой и объемный пункт, поэтому очень хочу порекомендовать к прочтению 2 книги:

Four Steps to the Epiphany – библия customer development, которая даст вам фундаментальное понимание об этапе создания продуктов, которые вам нужно пройти перед тем, как написать пользовательские истории.

User Stories Applied – самая лучшая и полная книга о том, как писать, оценивать, тестировать и принимать пользовательские истории.

Евгений Плохой, CEO at CapableBits, Founder of CBLabs.mobi

Я бы сказал, что user story – это инструмент. Инструмент этот обычно используют outsourcing компании. Он позволяет начать диалог с клиентом и работать в одной карте понимания задачи. Так что чаще всего user story пишет заказчик. Сам формат user story, который выглядит так «As !WHO! I want !WHAT! so that !WHY!» предполагает, что её пишет пользователь/заказчик, который объясняет ЧТО он хочет и ЗАЧЕМ. Мы разрабатываем продукты для глобального рынка и разрабатываем продукты самостоятельно, поэтому таким инструментом, как user story мы не пользуемся. Для нас более актуальными являются сценарии использования, которые мы в том числе используем для QA продукта.

1. Как правильно написать User Story?

Хорошая User Story должна соответствовать модели INVEST.

2. Как объективно оценить ее полезность и востребованность?

Объективно оценить её полезность и востребованность достаточно сложно, т.к. непосредственно в процессе разработки она не участвует, а служит отправной точкой. Это способ начать диалог без понятных маркеров его завершения. Субъективно для нас этот инструмент бесполезен.

3. Чего делать не стоит при работе с User Story?

• Использовать историю для выполнения которой требуется более одной итерации
• Писать громоздкие истории.
• Использовать жаргон.
• Сразу привязывать историю к конкретному интерфейсу.

User story от Юлии Козловой, PR & Event Manager в Touch Instinct

1. Как правильно написать User Story?

Не важно то, как она будет написана и оформлена. Главное – насколько правильно и точно она описывает потребности пользователя. В Touch Instinct мы проговариваем пользовательскую историю с клиентом устно, во время переговоров. Делаем заметки. Кто пользователи, чего они хотят? Мы выясняем формализованные потребности: мгновенная покупка, удобное чтение новостей, бронирование мест, заказ билетов и т.д., из которых прорабатываем детальные требования к сценариям использования будущей программы. «Я как пользователь хочу сортировать товары по цене, чтобы выбрать лучшее из одной ценовой категории». «Я как пользователь хочу сохранять музыку в кэш, чтобы слушать без интернета». Далее на основе юз кейсов строим интерфейс, на этом этапе мы понимаем, от какого функционала стоит отказаться, например,  нужны ли комментарии к фотографиям или нет.

2. Как объективно оценить ее полезность и востребованность?

Заказчик хорошо знает свой продукт и потребителя. На переговорах мы стараемся вытянуть из него максимальную информацию о том, чего хочет пользователь. Полезность юзер стори прежде всего в том, что они помогают разработчику лучше понять область, продукт, аудиторию заказчика. Мы не совершаем действий ради действий. Востребованность юзер стори оценивается обнаружением и проработкой пользовательских потребностей, на выходе продукт их должен удовлетворять.

3. Чего делать не стоит при работе с user story?

Не стоит зацикливаться и затягивать с проработкой. Зафиксировали ключевой функционал, держите его в фокусе, перед глазами, но не воспринимайте как инструкцию. Юзер стори достаточно гибкая вещь, в которую можно вносить изменения.

Наталия Давыдова, менеджер Heads and Hands

User Story обычно используется при гибких методологиях разработки. В нашей компании часть проектов ведется по такой методологии. Обычно мы организуем встречу с клиентом, на которой просим его описать обычным пользовательским языком пожелания к функционалу сайта или мобильного приложения. На основе этого мы составляем конечное описание работ для итерации (беклог). Правильный пользовательский сценарий, на наш взгляд, должен быть:

• понятным для всех участников проекта (и конечного пользователя);
• коротким, чтобы можно было оценить сроки его выполнения, но при этом с достаточно точным описанием;
• сценарий должен совпадать по смыслу и идее с основным проектом (чтобы очередная итерация «не выпадала» из общей идеи проекта. Это как раз слабое место гибких методологий, потому что при большом количестве итераций порой забывается основная идея и смысл проекта, он обрастает дополнительным и не всегда нужным функционалом, превращаясь в громоздкого «Франкенштейна»)

Объективно можно оценить полезность в том случае, если по user story можно сформировать удобный и понятный конечному потребителю продукта интерфейс.

При написании user story нужно стараться придерживаться максимально простого описания (без ухода в технические детали). Учитывать роли пользователей при работе с продуктом. Стараться не увеличивать размер истории. Она должна вписаться в одну итерацию, которая при гибких методологиях длится не более двух недель.

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.