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

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

Учитывая, что 70% программных проектов проваливаются из-за плохих требований. Оценочная стоимость повторной работы, связанной с этими провалами, превышает 45 миллиардов долларов в год.

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

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

1. Определите как можно больше персонажей, чтобы представить пользователей системы.Это поможет вам оставаться сосредоточенными на клиенте и управлять и отслеживать требования на основе потребностей клиентов. Введённые Аланом Купером, персонажи определяют типичных пользователей системы — примеры людей, которые с ней взаимодействуют. Пользователь не обязательно должен быть или представлять отдельного человека. Пользователь может также представлять организацию.
2. Убедитесь, что ваши пользовательские истории соответствуют «3C»:

• Карточка — Должна быть написана на карточке или на листке-записке
• Разговор — Получите подробную информацию от владельца продукта
• Подтверждение — Убедитесь, что он реализован правильно. Он должен соответствовать критериям приемки пользователем.

3. Разбивайте пользовательские истории так, чтобы они имели соответствующий размер и помещались в один спринт. Некоторые способы разбиения историй включают:

• Разбивка по этапам рабочего процесса
• Разбивка по каналам ввода/вывода
• Разбивка по вариантам действий пользователя
• Разбивка по персонажу/роли
• Разбивка по диапазону данных

4. Обеспечьте, чтобы каждая пользовательская история соответствовала мнемонике INVEST:

Агилмнемоника INVEST, созданная Биллом Уэйком, служит руководством для обеспечения высокого качества элементов продуктового бэклога (PBIs), как правило, написанных в формате пользовательской истории.

• Независимость: Истории должны быть как можно более независимыми.
• Обсуждаемость: История — это не контракт. История — это приглашение к разговору. История отражает суть того, что желательно.
• Ценность: Если история не имеет очевидной ценности, ее не следует выполнять.
• Оценяемый: История должна быть оценена или размерена, чтобы ее можно было правильно приоритизировать.
• Маленький: Для двухнедельной итерации пользовательские истории должны в среднем составлять 3–4 дня работы — в сумме! Это включает всю работу, необходимую для приведения истории в состояние «Готово».Чем меньше пользовательская история, тем выше точность оценки!
• Проверяемый: Каждая история должна быть проверяемой, чтобы считаться «Готовой».

• Написание SMART-целей и INVEST для пользовательских историй
• Тема против эпика против пользовательской истории против задачи
• Что такое DEEP в продуктовом бэклоге?
• Как написать видение продукта для проекта Scrum?
• Как использовать доску Scrum для гибкой разработки?
• Кто создает элементы продуктового бэклога или пользовательские истории в Scrum?
• Что такое гибкая оценка?
• Что такое балл истории в гибкой разработке? Как оценивать пользовательские истории?
• Разделение пользовательских историй — вертикальный срез против горизонтального среза