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


Написание пользовательских историй.

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

Все хотят идти Agile сегодня. Команды хотят поставить пользователя в центр процесса разработки своих продуктов при создании продуктов. В конце концов, вы создаете продукт для своих пользователей, верно?

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

Много говорилось о как писать истории пользователей,

Я, конечно, могу понять, почему они предпочитают другие варианты.

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

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

1. Слишком широкие пользовательские истории

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

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

2. Слишком хорошие истории пользователей

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

3. Не подлежит обсуждению

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

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

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

4. Повторение пользовательской истории в критериях принятия

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

5. Наличие неопределенного пользователя

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

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

6. Плохой контекст

Слишком много раз мы заканчиваем тем, что пишем истории пользователей ради этого. После определенного момента почти каждая пользовательская история начинает выглядеть одинаково.

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

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

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

Вывод

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

Дальнейшее чтение

Что такое пользовательские истории и кто должен их писать?

8 шагов для эффективных пользовательских историй

Магия маленьких пользовательских историй