The Problem with User Stories
“We are searching for some kind of harmony between two intangibles: a form which we have not yet designed, and a context which we cannot properly describe.”
— Christopher Alexander, Notes on the Synthesis of Form, 1964
User stories are one pillar of the agile methodology, or should I say mythology. Agile practitioners are encouraged to write short stories like: “As a (customer), I want (shopping cart feature) so that (I can easily purchase items online).”
User stories are supposed to replace the “overly technical” concept of requirements. In practice, they’re very similar. The problem with user stories, and requirements, is that they tend to focus too much on the product rather than the problem.
As Christopher Alexander explains in Notes on the Synthesis of Form,
“[…] every design problem begins with an effort to achieve fitness between two entities: the form in question and its context. The form is the solution to the problem; the context defines the problem. In other words, when we speak of design, the real object of discussion is not the form alone, but the ensemble comprising the form and its context.”
User stories are too restrictive. If our customers never purchase more than one item on our website, does it really make sense to implement a shopping cart? What if most of our customers already have an Amazon account, wouldn’t they prefer to purchase there instead? When you state a problem instead of a solution, you’re more likely to be creative. And our first idea is often wrong. Evaluating and documenting several options often leads to a better design.
User stories are too subjective. When there is no clear problem to solve, people tend to argue about features based on personal preferences and past experiences. As Alexander points out in his book, a solution works relative to a context: “one tie goes well with a certain suit, another goes less well.” When you state the problem you can discuss more objectively about the quality of the solutions. Does it solve the problem?
A design is made of hundreds or even thousands of decisions, large and small. In practice, it is not possible to make all those decisions at the outset of the project. The user interface designer or the programmer will inevitably have to make decisions while implementing the feature. If they know the problem being solved, they will have an objective criteria to make those decisions. And more importantly, they will not run the risk to ship a feature that doesn’t solve the original problem.
Finally, problems can change or disappear. Features don’t. If your software is defined as a list of features, the list will keep on expanding.
Identifying the right problem to solve is perhaps one of the most difficult part of design. But it is also the part that has the most impact on the success of the project. So, next time you encounter a user story describing a feature, ask yourself: “What problem are we trying to solve?” Write it down. And think about it.
