Are User Stories always the best way to capture agile requirements?

If you are in an agile team and don’t use user stories, you are probably in the minority. But if you do, are you finding that they are always the best way of capturing requirements? I have recently come to question the typical format of a user story and its suitability to all requirements sets. The committed agilists among you (and I count myself as one of you) might, at this point, be starting to splutter and spill your coffee, but please… hear me out. All else being equal, user stories are the best way of capturing and managing requirements that I have come across. But… there are one or two situations in which their use is potentially compromised.

The “As a… I want…So that…” format (or variations of it) has been around for a while now and has become commonplace. But have you ever found it difficult explaining the “so that…” part? Take a regulatory project, for example. All the stories are ” so that we comply with the legislation”. Not especially helpful, is it? But even if all the “So that…” clauses are the same, what are the implications in dropping that part of each user story, leaving just the “As a… I want…”? Probably not a lot to be honest, but does that make it no longer a user story? As long as it is clear how the individual stories contribute towards the goal of compliance, then I don’t see a problem. But is there then a better format for user stories under these circumstances? Or should we be using something else instead?

Let’s look at another aspect. User stories also work best because they deliberately defer the detail of each requirement until the team starts working on it. This is only possible because you have a Product Owner / Business Ambassador around to provide the detail behind the requirement as and when necessary. But what if you don’t? What if your Product Owner isn’t around for more than one day a week and even then you have to collar him between meetings? I know some of you are shouting “Get a different Product Owner”, right? In an ideal world, yes that might be the answer, but his replacement may be equally as busy and may not be as knowledgeable. So, let’s say you’re stuck with the guy you have. Do user stories still work as well? Not really. The limitation is in the deferral of detail concept. As noble an idea as it is, that is not always possible. The less active business involvement you have in the team, the less you can rely on vague or woolly user stories being sufficient to capture requirements. When the rest of the team need to be able to just get on with the coding and testing without the business being around, the requirements need to be more detailed, don’t they? More like little specifications, in fact.
Here are some options:

expand the “I want” part of the story to provide more detail,

attach supplementary materials (models, mock-ups, annotated screen grabs etc)

expand the acceptance criteria into full Specification by Example scenarios

Or has anyone come across a format for a teeny tiny specification that still meets the INVEST criteria (although without the Negotiable bit – IVEST)?