Как писать понятные и ёмкие user stories для команды.

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

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

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

Пользовательская истории состоит из:

1. Описания.
2. Критерий приемлемости.
3. Бизнес-правила.

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

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

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

– Пароль чувствителен к регистру.
– Поле электронной почты НЕ чувствительно к регистру.
– Пароль должен состоять из 5+ символов и буквенно-цифровых символов.
– Требования к паролю должны быть отображены в UI.
– Должна присутствовать проверка требований и вывод ошибок при их несовпадении.
– И т.п.

Критерии приемки помогают всей команде:

1) PM - быстро и доходчиво объяснить себе и команде, какие потребности пользователя должны быть удовлетворены.

2) Разработчикам – знать, что именно для этого нужно сделать и с какими условиями.

3) QА – увидеть, понять и прогнать тесты по данным условиям.

4) Дизам – воплотить всё это в виде интерфейса для пользователя.

3. Бизнес-правила. Это набор политик или правил, обычно налагаемых компанией в качестве средства формирования поведения на более широком уровне.

Примером бизнес-правила могут быть юридические (18+) или иные ограничения, например регистрация только аккаунта юридического лица на различных B2B-платформах.

😎 RUSPM