As I explained, collaboratively writing user stories is an interaction that teams can and should do, but you haven’t supported your argument that stories (and subsequent discussions about those stories) can’t begin with someone knowledgeable sketching out the basics and then be enhanced through team discussion. You present these things as almost mutually exclusive options (aka a false dichotomy), which is a common misunderstanding of the Agile Manifesto, which simply just says “over”, not “instead of”.
And you haven’t addressed two of the biggest failings of team conversations that build shared understanding, which I called out in my original reply. 1) The results of these conversations are rarely written down, which means that everyone remembers them a bit differently later. 2) Even when these conversations happen in writing (instant message, email, etc) the conclusions are rarely (ever?) collected in one place (the user story) where they can be referred to quickly and easily.
So while the team may bask momentarily in a moment of shared understanding, once the bullets start flying (and worse, when it’s time to present what’s been built to the stakeholders), that understanding is usually shown to be less than perfect, leading to the need for re-work.
Finally, user stories expressing functional and non-functional requirements has been a common part of many user story definitions for … over a decade? I’m not aware of a single, authoritative definition of user stories, but here are several examples:
“A User Story is a requirement expressed from the perspective of an end-user goal … A User Story is really just a well-expressed requirement. The User Story format has become the most popular way of expressing requirements in Agile … “
Atlassian Agile Coach stated that “User stories are system requirements often expressed as “persona + need + purpose.”
Mountain Goat Software explains that “Constraints or non-functional requirements can be easily handled as user stories.
Just Google “user story requirement” for more examples (for and against).
You may be interested in looking at Gherkin syntax for expressing user story requirements using “Given” preconditions, a “When” interaction between the user and the system, and “Then” postconditions resulting from the interaction. Gherkin also encourages the inclusion of unsuccessful as well as successful “Scenarios” in a user story, encouraging the team to think through the things that can go wrong rather than all to often focusing only on the “happy path”.
Is it possible that your objections to written user stories are because you’ve never really seen a well-written example? They take a little investment of time and energy, but when done well they can be incredibly effective and valuable.
