Matt Rhys-Davies | Ecommerce Business Analyst

User Stories Vs Requirements

By Matt
In Agile, Articles, Business Analysis
26th July 2018
6,009 comments
U

Work 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 quite quickly, and you may be wondering exactly what they are and why they are needed, or perhaps….required. 

Essentially both relate to capabilities that the software or process needs to provide in order to deliver value to the stakeholders. That can be value to the end user in terms of functionality that makes a site easier to use, or value to the business in terms of providing more detailed insights.    

The key difference lies in the formatting, the language used, the level of detail, and how the 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 that specific piece of functionality. 

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 specific language, and focus on simplicity as to what the user needsto be able to do, and how they will realise the value.   

Boundaries need 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; 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 insight into the value of the story and how it fits into the sprint goal 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 aExisting customer
I wantTo be able to repeat-order an order I have previously made
So that I canPlace an order quickly and easily and not have to search for products

Acceptance Criteria

GivenI am an existing customer
WhenI am logged in to my account
AndI have previously successfully completed an order
AndThose products are still sold
AndThe products are available
AndI click the re-order button
ThenA repeat order will be confirmed & shipped

Requirements

Requirements differ significantly in approach to user stories. Where user stories serve to provide a high level view of what the software needs to do and provoke a conversation, traditional requirements documents will be 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) with 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 to have well defined requirements produced up front, but I do 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 I’ve experienced more positive results when there is a strong collaboration between the team with persistent feedback loops with the client.      

About the author

Matt

I am London based Ecommerce Business Analyst & Technical Lead. Always keen to chat.

View all posts

6,009 comments