Stop using: As a ‘user’ I want to be able to ‘what’ in order to ‘why’


The user story format “As a <role> I want to be able to <what> in order to <why>.” is still one of the most used formats. Some have re-ordered the words and started with the <why> (like that makes any difference).

I believe the above format was introduced by Mike Cohn. Mike has done a great job explaining user stories to the world. The format makes clear who wants to do what and for what reason. The latter is mainly interesting to indicate the business value of the user story.

At the time it seemed a good idea, but we are now almost ten years ahead and we should stop using this format. The entropy of this format is simply too low. There is mostly the tedious and meaningless As aI want to be able to and in order to. Just these words are often good for more than 50% of the user story title. It bloats the user story title and when you have many user stories it makes it even hard to distinguish between them.

Don’t repeat yourself – is one of the famous “Delfs blue tile” sayings we use in the agile community. Well, this format is repeating yourself constantly and it is driving people (read: me) insane.

What about just keeping: <role> <what> <why> and transform it a bit. The <what> is usually some kind of action someone want to perform with the system. The <why> is often not even filled in for many user stories, since it is often not that evident why the user story adds value. This format has certainly not lead to less bullshit features, so I guess it is safe to say it did not meet the intended goal. Rather I’d like to see some <context> that explains any pre-conditions we are dealing with for a feature.

I’ve worked with the format <role> <action> <context> for several years now and I can honestly say I would not want to go back. The format suggested was not invented by me, but by Joshua Kerievsky of Industrial Logic.

We now get user stories like:

  • Admin adds new user with already used email address
  • Admin removes a user
  • Admin searches a user with a valid email address
  • Admin searches a user with an unknown email address
  • User logs in with invalid id and/or password
  • User logs in with valid id and password

Etc. You get the point. Happy story writing!