As a moron, I write all tasks in this format even though it makes no sense to do so, so I won't have to put up with business colleagues moaning.

As someone who has also been forced to write UserStory-tickets like this

I want to give you 👍

So that we can get more jokes like this on devrant

It's insane how the "AS persona I WANT to perform action SO THAT I reach this end goal" has become standardised even in cases where
* The persona is "user" 99% of the time. (if it was anything else like "admin" the ticket would have a separate tag or be in a different project)
* The end goal is superfluous since the action makes it obvious. If the ticket is "I WANT to bookmark an article in the app" it's so damn superfluous to add "SO that I can read it later"

it sounds stupid, until you work with no pattern and have to find out what your colleagues mean

@darksideofyay The persona model works great when you want business colleagues to explain functionality in a clear way.

When you literally just want a story on the board that's "Upgrade x service to spring boot 3.1" but your delivery guys insist you write "as a developer, I want the x microservice to be upgraded to use spring boot 3.1, so that we can make use of the new docker compose integration features for more seamless local running" then it's nuts.

I can relate with you, it is somewhat annoying. But the USER STORY is just one part of a well defined ticket.

For bugs I use the following sections:

USER STORY

STEPS TO REPRODUCE

REQUIREMENTS (optional)

CURRENT RESULTS

EXPECTED RESULTS

For features I use the following sections:

USER STORY

REQUIREMENTS

EXPECTED RESULTS

ADDITIONAL INFORMATION (optional)

I shit on stories a lot - but that's mainly coming from a perspective of working in small, quick agile teams where everyone is so involved day to day that these feel excessive.

There's a place for them.

They are useful when working with complex, long tickets with tons of people, in multiple teams. if you have a waterfallish process where you get formal requirements, build it, and have a Test-phase where a Test-team verifies these before "the big relase". (even if it's not oldschool waterfall, but you still allow some agile and iterations) Then it might be great to have user stories to ensure design and dev understand the gist of the feature intent by looking at some user stories.

For example if you're building the user interface for some medical software, where "as a nurse I want to" or "as a doctor I want to" is relevant.

Just get the sense sometimes smaller teams have people try to bring the same process into those teams, without actually needing it

@jiraTicket Absolutely, this kind of structure is super helpful when real users are involved, and they want to do something specific. Then I'm totally with you.

If I want to stick something on the backlog to address a library upgrade, security issue, scaling issue, etc. though - then it's pointless. But there's some (many) out there who still want the same format for these dev stories, which is nuts in my view.