Visit our new website :

Agile User Stories

One of the biggest challenges I faced when developing software was trying to get customers to agree what they actually wanted. Lists of features, ideas for a user interace, vague descriptions of the problem being solved and many other variations all found their way into my inbox. Starting with problem identification we then set about listing features that will combine to solve the problem for the users.

People always find it easy to describe things they actually do which is why user stories for agile development work so well. Instead of trying to define some abstract feature:

The software should be able to brew fresh coffee.

I could say:

I am a coffee drinker, I need to drink coffee as soon as I wake up otherwise I will be too tired to make it to work on time.

It’s too easy to make general statements about requirements and easy to misinterpret them. Consider the feature above, what one developer understands from the words “brew fresh coffee” may be quite different from the what the next thinks.

stock-photo-16806282-coffee-in-disposable-cup-with-plastic-spoonTo the experienced barista this conjures up freshly ground prime roasted beans served as an espresso for an unadulterated flavour. To a busy recently graduated accountant, constantly late for work, this may just mean instant freeze dried coffee from a vending machine. You see the problem?

The second description of the feature is focused on what the user (role – coffee drinker) does (action – drink coffee as soon as they wake up) and why (reason – they’ll be too tired to make it to work on time). While this is still open to ambiguity it tells us a lot more about the intention. It suggests that time is of the essence, it needs to be quick, the user is in a hurry. We can now start making better decisions about how to implement the feature.

For the user story above I have used this approximate approach:

"As a <role>, I want <goal/desire> so that <benefit>"

But there are many variations to this as you can see here. With all these approaches it can be overwhelming, which one is best? Some appear to be over complicated and result in lengthy user stories, becoming time consuming  and, well not very agile! What’s more, if the goal is to encourage as much live collaboration with the client as possible who really wants to read lengthy texts during a meeting?

What I see a need for is a simple standard-ish approach to defining user stories. One that doesn’t force the stakeholders to read and/or write lengthy descriptions. One that makes you think about the value the feature is going to add and whether it’s really needed or not. And perhaps, slightly controversially, be able to easily visualize simple relationships between user stories. Oh and all this has to be done live in meetings.

Visit our new website Go to