Monday 26th April 2026

User stories are not for requirements.

I will not be proposing a dramatic new way of doing things here. I will have succeeded if, by the end of reading this, you understand that there is a profound difference between a user story and a requirement, and that if we want to build better things, we should move away from "documenting requirements". This is a review of the practice of prescription vs exploration.

Kent Beck realised that requirements are problematic. He spoke about them in his book "Extreme Programming Explained" (read it if you have time) and called them "an antidote to requirements". So, what's so bad about requirements that we need an antidote to them? Well, for starters, someone else is telling the team explicitly what to build and how they want it to work.

It's not a good idea because it's too prescriptive and assumes the team are mercenaries, at the beck and call of the person (or committee) writing the requirements. "I have a requirement for this, now build it!". That is not how good teams operate. There is no creativity, no discovery, no autonomy. The pervasive issue today is that people have taken requirements, seen that nice user story format (as a, I want, so that) and decided that is the perfect place to write down their requirements. What's more, because they write it in that format, it's agile, right?

Wrong. You have written a functional requirement in a different format. There is a school of thought that this is valuable because it defines the "who" and the "why". I don't subscribe to this. Take this requirement for example:

I argue that the user story is just describing the functional requirement in a different format, and achieving nothing by doing so. The functional requirement is still there, just in a different format.

We are doing requirements.

So, where's this antidote? Well, we should endeavour to ensure that user stories come from users, not from the PO, not from your bosses, not from the business analysts. A user story is a story that a user tells about what they want to achieve that the team can then have a conversation about, experiment, and ultimately deliver something that provides a solution to the need identified in the story.

The bit that gets missed is in the middle. We have the story, we spec it to within an inch of its life, and then we build it to the spec. User stories give us a wonderful opportunity to assess what the user wants and experiment collectively to provide a solution to the problem. We do not document a requirement of pizza size selection and then build it, we need to hear what the user wants from their pizza ordering system, deliver things that we think might help, and then measure the success or failure of the thing we built.

That's a user story. A story from a user. I can't imagine that as a requirement, but it sure is a great placeholder for a conversation. After all, that's what user stories are meant to be used for, right? The conversation that leads to the discovery of the right thing to build is why we do user stories, and need to stop doing prescriptive functional requirements dressed up as user stories.