This seems to be a worthwhile exercise to explore -- formal but lightweight, and a lodestone during development.

That said, a ticketing system should ostensibly offer this same effect, but in my experience they're often populated with brief titles and maybe a short paragraph on expectations.

We usually use this before tickets are even created. In many cases, an RFC can lead to an epic-level ticket that includes multiple user stories.

In other cases, it can be very tactical. I think you are right, probably it can be expressed directly in the form of a ticket. The discussion well happen in the comments to the ticket in this case.

Ticketing systems inevitably get Goodharted. Everyone starts in good faith, then the manager starts using the number of tickets closed, touched, etc as a proxy for work being done, then the agents replace number of tickets with things actually accomplished.

> That said, a ticketing system should ostensibly offer this same effect

If the ticketing system were private to the engineers, it probably would serve the same purpose. But inevitably ticketing systems have wider visibility, and become a mechanism for signalling progress to management/product/sales... at which point engineers are actively incentivised not to put actual data in the ticketing system

> a short paragraph on expectations.

or worse, multiple bulleted paragraphs fulls of expectations that have little to do with how the software actually work and is used by the actual users.