Working in any technology focused company or industry (predominantly ecommerce business analysis for me) and you’ll come across the terms user stories, and/or requirements within a short space of time, and you may be wondering exactly what they are and why they are needed.
Well, both essentially relate to abilities that the piece of software needs to provide in order to deliver value to those who will be using it. That can be value to the end user in terms of functionality that makes a site easier to navigate, or value to the business in terms of more detailed insights being provided.
The key difference lies in the formatting, the language used, the level of detail, and how teams responsible for delivering the features and functionality, work to build the software.
User Stories
The key element to understanding a user story is that it is not a prescriptive and defined method of delivering software; it acts as an artefact that provokes a discussion (Ron Jeffries – 3 C’s: card, conversation, and confirmation) by the team about how they will build and deliver the software that fulfills the user story.
A good user story is written from the perspective of the user (see persona’s in agile by Roman Pilcher) who will be using the feature, and as such will avoid domain specific language, and focus on simplicity as to what the user wants the system to do, and what value they will derive from the specific user story.
Boundaries are also needed to be defined as to where each story ends, and when exactly can we say that the story has been fulfilled or finished; these are the acceptance criteria. Ie, what the team can demonstrate the user story will achieve.
The creation of user stories are not the sole reserve of any one role on the team, although it will usually be a Business Analyst or Product Owner as they will typically have greater insight into the value of the story, and how it fits into the overarching goal of the sprint or the project plan.
So putting it all together, an example user story for an ecommerce website feature for making a repeat order would be as follows. This is following the pattern of Given When Then acceptance criteria.
User Story
| As a | Existing customer |
| I want | To be able to repeat-order an order I have previously made |
| So that I can | Place an order quickly and easily and not have to search for products |
Acceptance Criteria
| Given | I am an existing customer |
| When | I am logged in to my account |
| And | I have previously successfully completed an order |
| And | Those products are still sold |
| And | The products are available |
| And | I click the re-order button |
| Then | A repeat order will be confirmed & shipped |
Requirements
Requirements differ significantly in approach to user stories; where user stories essentially serve to provide a high level view of what the software needs to do and provoke a conversation, traditional requirements documents will be highly detailed and go into granular detail about how a system needs to act.
Requirements Example
- Allow the user to re-order an existing order
- Allow the user to change the quantity of items
- Group fields together
An example in differences between a user story and a requirement, the requirements document is generally used by the developers as a blueprint on how to build the software. Whereas a user story will state what the software needs to do, but architecture decisions are purely in the hands of the people building the system.
User stories are consistently broken down into small, executable component parts – ideally to sing to the INVEST tune – which can be discussed, and then fleshed out. Whereas requirements documentation is already fleshed out and ready to be turned into code.
Which Is Better?
Having worked in Agile environments (mostly Scrum) under various different hats – Business Analyst, Developer, Product Owner – for the past few years, picking up the various certifications on the way (Scrum Master, Product Owner); whilst also having worked on a number of waterfall-ran projects, and working towards the more traditional British Computer Society’s International Diploma in Business Analysis, I’ve gained useful insight to the pros and cons of both approaches, and I would always favour user stories.
I can appreciate – at least theoretically – the need in certain projects to have well defined requirements produced up front, but I would always much prefer to work with user stories; going through a requirements engineering process seems to place an implicit focus on the silo of functions, where analysis is kept separate from development which in turn is kept separate from testing. Whereas on the projects I’ve worked on, I’ve experienced more positive results when there is a strong collaboration between team members; bringing together a variety of experiences and outlooks to develop functionality.
