Кто же пишет User Stories (пользовательские истории)? (¬‿¬)

Довольно часто в команде возникает вопрос “Кто же должен писать User Stories (пользовательские истории)?” и порой решение этого вопроса приводит к конфликту внутри Agile-команды. Я специально использую термин “Agile-команда”, а не “Scrum-команда”, так как некоторые читатели могут сказать, что в Scrum ничего не сказано про User Stories и они будут правы.

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

Итак, моё погружение было с участниками двух комьнити ᕙ(⇀‸↼‶)ᕗ:

1. Serious Scrum с кем мы активно обсудили данную тему в slack (serious-scrum.slack.com)
2. Agile Mentors (https://www.agilementors.com), где на вопрос ответил по видео Майк Кон Mike Cohn

Однако, обо всём по порядку (• ◡•)

Serious Scrum: здесь активность запустил один из участников, который попытал счастье найти ответ на вопрос — есть ли что-то что развенчает миф, что владелец продукта единственный, кто пишет пользовательские истории

И так как это комьюнити Scrum, то человечка отправили в Scrum Guide, в котором нет ничего про User Stories, однако, логично предположить, что это один из подходов ведения бэклога продукта поэтому ответ был таким: владелец продукта может делегировать данную работу команде разработки, но при этом остаётся ответственным за то, что творится с бэклогом продукта.

Казалось бы бинго — мы решили дилемму и владелец продукта сказал команде — пишите пользовательские истории сами. И… scrum-master на воркшопе по написанию пользовательских историй получает не очень приятную обратную связь — “Чё это мы?!” ٩(͡๏̯͡๏)۶

Итак, читатель, возможно, у тебя в голове появилась светлая мысль, почему такое случилось... (¬‿¬)

И в этот самый момент, мы обращаем внимание на две статьи, которые рекомендовало комьюнити:

1. https://www.scrum.org/resources/blog/story-writer-misunderstood-product-owner-stance В этой статье интересно раскрывается роль владельца продукта, который кропотливо, как бизнес/технический аналитик оформляет свой бэклог продукта, погружается в детали, так чтобы команда уже ничего не спрашивала, сам всё декомпозирует и оценивает и… не имеет стратегического видения развития продукта. Конечно, это жёсткая крайность, но она случается в реальной жизни и нужно задаться вопросом, этот человек точно владелец продукта и какие всё-таки функции у владельца продукта?
2. https://www.scrum.org/resources/blog/myth-product-backlog-maintained-exclusively-product-owner В данной статье бОльшее внимание уделяется слову единственный, т.е. владелец продукта единственный, кто ведёт бэклога продукта, конечно, же это не так и тут мы перебежим с вами в другое комьюнити

Agile Mentors: так как изначально разговор пошёл про user stories я не могла не обратиться к Майку Кону (Mike Cohn) — автору книги User Stories Applied: For Agile Software Development и автору тренинга Better User Stories (который я прошла с большим удовольствием).

Вопрос был специально сформулирован с акцентом на то, что это работа владельца продукта— так формулируют вопрос участники команды.

Ответ Майка был очень прост и ожидаем — владелец продукта несёт ответственность, но не единственный кто ведёт бэклог продукта (так как видео только для участников комьюнити, ниже ссылка запись с телефона) ʕ•ᴥ•ʔ

https://drive.google.com/open?id=18z7UKW9AIEUFiQASKaexL2lbgxxjsS-b

Так как вопрос с пользовательскими историями плавно перешёл к ведению бэклога продукта, тот и лежит ключик к решению вопроса.

Бэклог продукта — это не только пользовательские истории, он включает в себя:

• баги, которые команда разработки не правила в текущем спринте;
• технический долг, который создаёт команда разработки и в дальнейшем должна уделить время на его устранение;
• технические истории, когда команда подготавливает архитектуру для будущего продукта;
• также ряд команд пишет в бэклог продукта решения (action items) с проведённой ретроспективы

Т.е. бэклог продукта включается в себя всё, что связано с развитием и поддержанием продукта.

Посмотрев на этот список, задумайтесь, как оно будет, если всё будет делать только владелец продукта?

Какое бы решение не приняла команда, я всегда призываю к эффективности и рациональности принимаемых решений. Отвечая на вопрос “Кто же должен писать User Stories (пользовательские истории)?”, попробуйте ответить на вопрос, что вы хотите получить в итоге:

• структурированный и понятный бэклог продукта (и можно углубить вопрос: <…> в Jira?)
• всё ли может написать Владелец продукта, будет ли это эффективным?
• чьё время наиболее эффективно и рационально инвестировать в данную активность?
• возможно, мой читатель, у вас появились ещё какие-то вопросы?

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

Справочно:

Epic — большая история, которая не помещается в спринт

User Story — пользовательская история, которую команда разработки успевает сделать за спринт (состояние potentially shippable — потенциально готовый к поставке инкремент)

Task — техническая история (например, создание архитектуры для всего продукта и не может быть рассмотрено как sub-task к пользовательской истории)

Sub-tasks — работы команды, которые необходимо сделать для реализации User Story/Task