Як написати якісний User Story statement?

[@yuriyhlushchenko369]

Дуже подобається такий формат. Дякую за цінні знання! Будь ласка, не зупиняйтесь.

[@AlexCherkassky]

Дякую. Завжди приємно дивитись та слухати.

[@badassba]

І завжди приємно читати такі відгуки. Не зупиняйтесь)

[@marynatsybak2591]

🔥 мерсі) я тут по ютубчику шукала інфо про юзерсторі, приготувалася ламать вуха на англ контенті, а тут Ви. Дяка

[@badassba]

Прошу )

[@Heavy_Ant]

дякую, формат зацікавив! давайте більше!

[@enajj]

Дякую! Такі чисто практичні речі дуже помічні

[@KvKosteg]

Супер, це те що треба - зтисло, змістовно, та практично!

[@iramelnichyk1785]

Формат зайшов! Дякую за відео

[@viktoriadreamlook5030]

Святі джейсони, як же не вистачало такого контенту, дякую!

[@marianak7721]

Класний формат! Давайте ще ;)

[@annVKh]

супер формат, відчуття наче нарешті хтось дав фідбек особисто мені стосовно якості моїх юзер сторей))

[@tanyanaliotava9447]

Absolutely kickass blog. Keep it up!

[@badassba]

Thanks! Tell your friends!! ;-)

[@incFlow]

Дякую за відео! Класний формат! Можливо в Вас би було більше переглядів, якби Ви змінили назву "відео блог№1" на назву, яка відповідає темі відео)

[@badassba]

дякуємо, в наступних епізодах вже здогадалися так зробити )

[@olesyafedotova5321]

Супер, хочу ще:) відмінно, чітко, зрозуміло.

[@eugenek777]

Чудовий гайд - давайте ще)

[@JoeyHarasym]

Кириле, велике дякую за це відео. Тема, про яку я не втомлююсь кричати!) Проблема шаблону user story в тому, що його використовують саме як "шаблон", "бо всі пишуть юзер сторі, тому ми теж будемо їх писати", часто не розуміючи ні суті, ні значення цього формату 🤷🏼‍♀ Я проводила у себе на фірмі презентацію. "Top 10 user story mistakes", де як могла, пояснювала, чому слід уникати по можливості слова user, або додавати до нього контекст (As a user who is searching for an item in a long list), чому в частині I WANT TO слід фокусуватись на проблемі, а не на рішенні, і чому частина SO THAT найважливіша (в нас її часто навіть ігнорують 🤦🏼‍♀) Мені поаплодували, понаписували гарного фідбеку, та й далі пишуть сторьки як і до цього 😅

[@badassba]

:) будемо далі лупати цю скалу

[@shchekavytsia]

Дуже дякую!!!! Мільйонних переглядів не буде, але дуже корисне відео. Як тільки рейт ЗП дозволить- іду в патреон)

[@badassba]

Як це, не буде мільйонних переглядів?? (((

[@shchekavytsia]

@@badassba дуже вузька тема. Половина населення таких слів не знає))))

[@badassba]

@@shchekavytsia треба навчити )

[@oleksandrapiasetska4685]

Можете записати таке ж відео по юз кейсам? А також цікавить тема автоматизації процесів через інтеграції систем. Як документувати вимоги для таких проектів? Наперед дякую 😊

[@annVKh]

Плюсую до інтеграції систем. Кожен проект по різному це робить

[@alexrybalka9403]

топ актерочка! ну и контент норм

[@badassba]

А мы ведь толком еще ничего не начинали ;-)

[@khoroshchakyurii6171]

😃nice

[@illyriomusic]

Hi Kyrylo, thanks for this blog. What I want to say here is that I feel the plain "user" term (in the user story statement) does not always deserves so much criticism. I understand the need to be precise about who exercises a given capability of the product, but I can also point out scenarios where the plain "user" term is good enough, especially if augmented with some detail inside the Story. For example: 1) Some products have two "users". A typical example could be "a user" and "a user with paid subscription" (or "a logged in user" and "a non-logged in user"). Consider a gym app where you can be a user with or without a subscription. A good amount of app's capabilities is available to both types of users, so for these, saying "As a user" is completely fine. For capabilities accessible only to users with a subscription, we can add this detail either i) in the User Story Statement: As a user with subscription OR ii) in the Detailed Description of the Story: (...) and if the user has a subscription, then (...) 2) Other products have a set of roles that can be assigned to users in multiple combinations. Let's consider a case of a dozen roles or more (a realistic example from my experience). Using all possible combinations of roles or defining Personas for each combination and then using them in the User Story statement would be highly impractical in that case. I believe it is much better to accept "a user" in the User Story statement and add the logic related to roles in the Detailed Description, for example while explaining the scenarios: (...) but if the user also has the Administrator role, then enable (...) 3) Finally, the plain "user" term is also perfectly fine when we are precise about the user's intent outright in the User Story Statement: As a user whose credit card validity expired (...) Next time you spot the "as a user", please don't be too quick to criticize it.

[@badassba]

Hi illyriomusic, thanks for such an extensive comment. In your example 1 “user” term is perfectly fine unless we have other user-roles e.g. gym membership manager or someone, who is also a user of a system but not a customer. I’d prefer stating “gym member” of ”customer“ at least. Example 2 and 3 - I totally agree

[@viktoriadreamlook5030]

А тепер питання, як краще описувати технічні історії, типу енви розвернути або міграцію зробити. В житті воно завжди зрозуміло як, але буде цікаво почути приклади з вашого досвіду, дякую!

[@badassba]

Дякуємо за запитання. Про тему форматів цікаво буде зробити окремий випуск.