Сложные истории — это те, которые нельзя разделить. Они по своей природе большие и/или сложные, и в них нет частей, которые можно было бы разделить на отдельные истории. Что делать с такими историями?

Пользовательские истории часто поначалу преднамеренно расплывчаты, если работа над историей не начнется в течение нескольких будущих спринтов. Agile-команды поняли, что добавлять детали в историю заблаговременно нецелесообразно. Но в жизни любой пользовательской истории наступает время, когда нужно добавлять детали. И есть два способа, которыми команда может добавить детали в пользовательскую историю: разделить ее или добавить критерии приемки (Acceptance criteria). Рассмотрим подробнее оба метода.

Статья о том, что делать, если с менеджером не получается найти общий язык. Возможно просто дело в том, что вы разных типов? Говорим про Органиков и Механиков.

Я хотел бы прояснить взаимосвязь между двумя важными понятиями: командным определением Критериев готовности (Definition of done) и Условий удовлетворенности (Conditions of Satisfaction) для пользовательской истории.

В рамках своей работы и ведения подкаста по бизнес-анализу (ссылка на подкаст), я часто получаю вопросы от бизнес-аналитиков. И один из самых частых - как задокументировать нефункциональные требования, если на проекте принят стандарт написания пользовательских историй? Сегодня, я хотела бы поделиться переводом статьи Майка Кона, о том, как описать нефункциональные требования с помощью пользовательских историй.

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