Working in a various Scrum / Kanban / SAFe teams, I see this "As a $PERSONA, I want $NEED, so that $PURPOSE" pattern a lot. For example:
As an Agile team member, I want user stories, so that the value we create for users is always clear.
Then I read the book Agile! The Good, the Hype and the Ugly by Bertrand Meyer which considers user stories one of the worst aspects the Agile movement popularized.
User Stories are not Requirements
Wikipedia traces their history back to Kent Beck in 1997 and his publication Extreme Programming Explained two years later. The Wikipedia article starts like this (emphasis mine):
In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index cards, Post-it notes, or digitally in project management software.
Bertrand Meyer uses a similar definition (page 119):
User stories provide the basic unit of requirements in agile methods.
And two pages later his criticism:
Relying exclusively on user stories as the source of requirements [...] is not sufficient for the design of solid systems. This narrow focus is one of the main limitations of agile methods.
Here is how it might play out in practice: Them team receives all kinds of wishes and ideas from users. They turn them into user stories and store them in their product backlog. They identify the most valuable ones and deliver some. The other ones are ignored until the product owner deems them valuable enough. Eventually, one of the older stories gets attention and they realize that an expensive redesign is necessary. If one would have considered the requirements as a whole, a different design would have been chosen initially.
Wait a minute. The core assumption of Agile is that requirements always change, so isn't this futile? We need to phrase this with more nuance: For a solid design a holistic understanding is critical. For example in Scrum terms, "holistic" means you should consider the whole product backlog and not just the current sprint backlog. This is no guarantee that no architectural change will become necessary but it mitigates this costly risk.
Isn't it hard to keep an overview of all backlog items which consists of barely comprehensible user requests and ideas? What about the things they told us, which are not even in the product backlog? Nobody said it would be easy. The claim is that proper requirements engineering is more effective than staying ignorant and just focus on immediate user stories. It relates to another criticism of Agile in Meyer's book: Upfront work and requirements are discouraged by Agile.
Good requirements are useful. User stories are not good requirements.
Still, Meyer does not eschew user stories completely:
Their unique role, like that of tests for specifications, is a validation mechanism for requirements and designs. Higher-level requirements have the advantage of abstraction and generality, but run the risk of impracticality: of missing cases that are important to users. Listing user stories is not a replacement for writing general requirements, but is an important step to make sure that nothing has been forgotten.
In other words, user stories can help you to improve your requirements but they are not requirements themselves.
Well, there is some evidence that user stories help, like The Use and Effectiveness of User Stories in Practice:
User stories are an increasingly popular textual notation to capture requirements in agile software development. [...] The data shows that practitioners agree that using user stories, a user story template and quality guidelines such as the INVEST mnemonic improve their productivity and the quality of their work deliverables.
There is also evidence that user stories are harmful, like User Story Quality in Practice: A Case Study:
In this project, relying on the user stories would have been a disaster. Although the user stories could have been improved, they wouldn’t cover the necessary requirements in the project.
My opinion is that user stories as requirements are probably a bad idea. Bertrand Meyer is right. Evidence in favor is weak and might rather be a statement about the poor state of requirements engineering than about user stories.
User Stories as Work Items
User stories as requirements seems to be the dominant understanding. However, they can be understood differently. For example, look at Atlassian's description. As one of the largest provider of tooling for Agile teams their understanding has some authority.
It's tempting to think that user stories are, simply put, software system requirements. But they're not. [...]
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.
Funny that the Scrum Guide, the most famous agile framework, does not mention "user stories" at all, only "backlog items". Also, the last two sentences contradict each other: Do user stories describe features or not?
Anyways, the good thing about the description is the acknowledgement that user stories are not requirements.
User stories are "units of work" apparently. That means the $NEED part is essential. Customer needs something, we build and deliver it, and everybody is happy. This means the $PERSONA and $PURPOSE parts are extensions. How would they be useful?
I have never seen any team actually using a personas. Everybody uses roles or job titles instead. The idea of user stories is that a persona provides a lot of context. a job title does not though. Citing Atlassian again:
"As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.
The $PURPOSE is also about context. It is often not obvious why satisfying $NEED is valuable to a user. Developers are often irritated by strange user needs. So I understand the emphasis to explain the purpose better. In practice, it often goes wrong when a developer writes a user story without knowing the purpose. Instead of finding out about the user, they just rephrase the need then. Try it:
As an Amazon customer, I want to purchase something with 1-click, so that...
Personally, I don't know the answer. I never used that button. The point is that it isn't easy to determine the purpose. It requires effort.
Now let me summarize and you can decide if we have the same understanding of user stories here: A user story describes a work item. It puts extra emphasis on understanding your users and why satisfying their needs is valuable to them.
I don't see anything wrong about user stories as work items. However, it requires the additional effort of defining Personas and always specifying the purpose. It probably depends a lot on your domain if it pays off. Personally, I work in a Tier-1/2 on automotive software and in the core business Personas make no sense. I would prefer my colleagues would stop writing user stories. If you build a web service and directly deploy to users, it might well be a good idea. So I do not advise against them in general.
Final verdict
User stories as requirements. No, bad idea.
User stories to improve requirements. Looks useful but requires effort.
User stories as work items. Not for me.