There are a lot of articles out there about teams who think they are Agile but in fact are not. Or teams who are struggling to transition to Agile for one reason or another. The same also often applies to the usage of User Stories.
User Stories are not a pre-requisite to Agile, but they are commonly used within Agile teams (or pseudo Agile teams). The trouble with User Stories, as with Agile, is that they seem to be one of those things that open themselves up to too many people getting a “loose understanding” of and then base entire projects around. This often has the effect of losing many of the benefits!
Let’s take a look at the definition of a User Story. There are variants, but the most common is:
As a <role>,
I want <a goal>
so that <business benefit>
This is a simple, yet very powerful way of describing a feature. Typically features would then be “fleshed out” with either Acceptance Criteria, Behaviours, wire-frames or other useful material (or a combination).
However, there are many traps that the inexperienced or unlearned fall into. Some of the most common I summarise below.
- The “Epic”
– first up on the list are massive user stories, also known as Epics. These are not bad per se, but are too big for development in a Sprint and need to be broken down. An example might be “As a Banker, I want a way of trading in real-time, so that I can execute more trades and make more money”.
- The “Vague User Story”
– Fairly easy to deal with as a QA professional – you just need to elicit a few more details. An example here would be “As an Adminstrator, I need to be able to access my users details in a timely fashion, so that I meet my legal SLAs”. What is a timely fashion here?
- The “Lying User Story”
– Gojko Adzic recently wrote an excellent post on this. His example being “As a User, I want to register, so that I can login”. No user WANTS to register. Further more, logging in itself is not the business benefit.
- The “Technical User Story”
– There are two main ways this horror-story comes about. Firstly, a way of quickly completing a well-written User Story well is to dump re-factoring, unit testing and other good forward-thinking technical activities out into a “technical story”. These stories might simply be written as “As a Developer, I want to re-factor code X”. Secondly, when there is too little conversation between the team and they are being handed requirements top-down, you may end up with stories like “As an email system, I want a database, so that I can store emails”. This destroys many of the advantages of User Stories – there is no focus on WHY the business wants this feature developed and the team has already been told how to implement it!
- The “Userless User Story”
– I’m meant to write “As a user” aren’t I? Well, yes and no. There may be cases where there is simply one generic user, but in most cases (and if enough thought is given), different types of users can be found. Even if it is just one user, it may add something to story to describe them in business terms – if the end user is an Account Manager, a Data Analyst for example.
- The “Motiveless Story”
– Similar in a way to the Userless User Story where not enough thought is given to WHO the user is, the motiveless story is one where nobody has bothered to ask, discuss or write down WHY the user wants this feature at all. Correctly specifying this will give much more insight to a team who can ask much better questions. Generally you will not find the “so that…” section blank, but it will often contain platitudes such as As a Banker, I want a list of available Futures Contracts, so that I can look at the Futures Contracts List”. Is that really why the banker wants the list?
There are many more poor examples out there which suffer from more the same issues as other requirements types – the ambiguous, the untestable and many others. The list above though illustrates a number of ways that requirements may be masquerading as User Stories but in fact are nothing of the sort.