[captain_crabs]

I haven't read any further comments on purpose, immediately logged in to reply because I have a prediction:

People are going to say the user story you listed is _way_ too vague, general, or otherwise "not right" or "something they've never seen." They're going to reject it/pick it apart for a litany of reasons, all of which triangulated against their individual experiences. Me too! Here goes:

I've found "user stories" miss entire dimensions of context from the business side which are incredibly important to developers. In lesser-performing orgs, this is often a way the "business folks" (and yes - in some orgs, there is a distinct divide) wield information asymmetry to pawn off blame onto devs when "things aren't right." This information about how people are really gonna use the software vanishes somewhere along the way before it turns into a user story. This post gets at the heart of it pretty well: https://jtbd.info/replacing-the-user-story-with-the-job-stor... (which, btw, if this makes sense to you, is something you're strangely passionate about, and you're not familiar with "jobs to be done" then go get intercom's free ebook on it right now)

I have another guess. This is less of a prediction, more of a thing I'd like to find out: of all the people who reject your user story, how many of them have worked at places where their product manager isn't a technical person?

My guess is: most of them. I'm also guessing PM's get super specific because developers moan at them over minutiae, info gets cut out/they don't realize it's important, and there you go.

I'm betting most orgs adopt agile as a means of combating poor engineering dept performance, and generally (not all the time - but generally) this is directly due to the people managing the technical people not knowing what they're doing, so it's essentially a set of default behaviors that protect both sides and guarantees some minimum (read: not maximum) of performance. So these product managers who don't understand any development are put in charge of developers consider writing tickets their job, and instead of understanding reality -> reflecting that in tickets, they write their tickets and try to coerce reality to follow.

Frankly, take a bunch of people who already didn't want to change their process, force them to hear "you should update your process that's how things are supposed to be" every day, and after a couple months they actually start to do it.

Ticket shaping is super hard. I don't trust a non-technical PM to do it right, unless they happen to be experienced and/or have devs alongside them who are essentially just doing their job for them. Add onto this the fact that typically management consider all parts of software development a linear process.

Not to say you can't have PM's who are nontechnical, and can bring all the right context/organize everyone in the right ways. I believe they exist, I just haven't worked with any. Devs are generally ineffective at communicating technical context in non-technical ways, and reality is an emergent mix of both business & technical.

this has turned rambly. tl;dr - user stories are such a vague/overloaded concept for so many reasons, if you have the choice read up on "job stories" and try and switch to those. They're no less confusing to implement, but they force you to find answers to much better questions.

[captain_crabs]

And final thought, "correct" or not, a guiding principle that's proven useful over time: individual tickets should deliver true pieces of "value" which is to say, once deployed, the software does more of what people need than before. So when a ticket is "done," it means something was improved however it was needed across all levels of the stack.

None of this "button here" "wire it up later" "now add the db table" etc.

[bloomca]

I think it is possible only in simple software (when you are developing an MVP, or just early stages).

Complex tasks are incredibly hard to finish as a single ticket – with such granularity you might have opaque progress for couple days, and you hide a lot of details from everyone.

Unless you mean "tickets" as "user stories", they can be (although not always) treated like that.

[captain_crabs]

God I can't stay away from this thread.

Yeah - entirely depends on your subdivision vernacular. Some people make subtasks in a ticket, some people make tickets linked to other tickets, some people do both and link those to "features" which are themselves tickets (like the environment I work in).

Just depends!

[captain_crabs]

Sounds like we agree, but use different names for the same things and some of the same names for some different things! :)

[fatnoah]

>Ticket shaping is super hard. I don't trust a non-technical PM to do it right, unless they happen to be experienced and/or have devs alongside them who are essentially just doing their job for them.

It is very hard. At my last gig, we got to a generally good state where the PMs were responsible for periodically outlining their overall "vision" to the team, which captured what we're building and why we're building it. In stories, PMs were made to be very focused on focusing on "what", not "how", and to provide the context for "why". That let the PMs stay out of technical details and let the Engineers use their brains to fill in gaps.

It took some pain and effort to get to that point, but once we got there, it worked very well.