Как писать User Story

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

Структура user story

  1. Есть один actor
  2. Есть одно действие
  3. Есть одна ценность / value / impact. Я выделяю ее ЗАГЛАВНЫМИ БУКВАМИ при написании User story.

Actor

  1. Разделите всех актеров на группы. Целевая группа, важная группа, менее важная группа и тп.
  2. Дайте уникальные названия актерам в этих группах. Даже если в системе у них будет одинаковые роли “Пользователя системы”
  3. Пишите истории с точки зрения этих актеров указывая их уникальные названия.
  4. В результате вы сможете визуально увидеть какие истории необходимы для актеров целевой группы, какие — для каждой группы и тп. Вы не просто можете использовать это при разборе истории и выстраивания анализа вокруг указанного актера. Вы сможете более правильно выстроить приоритет, так как истории актеров целевой группы для нас более важны.

Действие

Ценность

  1. Вы построили Impact mapping
  2. Вы определили Цель и метрику на нее. Например, “ускорение сроков согласования инвестиционных бюджетов”.
  3. Вы определили что “инвестиционный аналитик” может вам помочь в достижении этой цели.
  4. Вы сделали предположение что если аналитик будет получить отчет №17 быстрее, то это приведет вам к вашей цели.
  5. Потому данная история — это проверка данного предположения достижения цели.
  • Independent. Reduced dependencies = easier to plan;
  • Negotiable. Details added via collaboration;
  • Valuable.
  • Estimable. Too big or too vague = not estimable;
  • Small. Can be done in less than a week by the team;
  • Testable. Good acceptance criteria;

Наиболее распространенные ошибки при написании историй

История для юзера

История для продакт оунера

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

  • «Отрефакторить механизм добавления папок, чтобы позволять создавать вложенные папки вплоть до 3 уровня вложенности»
  • «Проапдейтить версию SDK для использования нового механизма локального хранения данных на устройстве»
  • «Пользователь может создавать папки с тремя уровнями вложенности»
  • «Пользователь не может создать больше 100 папок»

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

Никаких критериев приемки

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

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

Сомнительные практики

  • Слишком формальные/слишком детализированные задачи. Иногда владельцы продукта с самыми хорошими намерениями стремятся писать слишком детальные истории. Если на встрече по планированию итерации команда видит набор историй выглядящий как многотомная спецификация, то искушение предположить, что все детали отлично освещены и пропустить обсуждение, очень велико.
  • Не пропускайте обсуждения. Истории для этого и обсуждаются на планировании итерации, чтобы вскрыть неясные моменты, уточнить все детали и получить полное представление о задаче. Если вы не обсудили их всей командой, вы рискуете начать двигаться в неверном направлении во время разработки.
  • Перестаньте выдавать технические задачи за истории. Если вы пытаетесь втиснуть в формат истории технические задачи, то в конце итерации у вас точно не появится готовый кусочек продукта. Если технические задачи действительно нужны и у них есть ценность для каких-либо пользователей (в том числе и внутренних, в вашей команде), то смело оформляйте их в технические истории, но не составляйте всю итерацию из подобных задач, ведь у вас, вероятнее всего, есть и бизнес-клиенты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример разработки User Story

ВОПРОСЫ?

КУДА ДЕЛИСЬ ДЕТАЛИ?

ПРИМЕР ДЕТАЛИЗАЦИИ.

МОЩНЫЕ ИНСТРУМЕНТЫ РАБОТЫ С ИСТОРИЯМИ: УПОРЯДОЧИВАНИЕ, РАЗБИЕНИЕ И ГРУППИРОВКА

ДИНАМИКА ЗНАНИЙ

ЧТО ДАЛЬШЕ?

P.S.

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Tvar

Alexander Tvar

More from Medium

Zomato App — Agile Methodology

Scrum for Small Teams with Multiple Stakeholders and Projects

Agile management adoption roadblocks & solutions

A team discussing their work together.

An attempt at estimating a sprint’s Story Points capacity