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

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

И так как это комьюнити 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 В данной статье бОльшее внимание уделяется слову единственный, т.е. владелец продукта единственный, кто ведёт бэклога продукта, конечно, же это не так и тут мы перебежим с вами в другое комьюнити

Так как изначально разговор пошёл про 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) и закрепить в командных соглашениях, так вы сохраните мотивацию и доверие — а это очень важные составляющие эффективной работы команды.