Anyone practising agile, or more generally anyone attempting to build software will likely have come across the concept of user stories. A user story is a tool used in agile software development to capture a description of a software feature from an end-user perspective.
The user story describes the type of user, what they need and why. A user story helps to create a human (non-technical) description for a requirement.
This helps to keep us focused on who we are developing our products for.
It helps to ensure that the person using the software has been considered when decisions are made.
Teams will find that they help us to deliver better software, more often.
A set of well-defined, prioritised user stories help to articulate the functionality of our products in plain, understandable language – with no technicalities or implementation details so that all members of our team internally and externally can share the same vision for the feature in question in an ubiquitous language.
Examples of user stories
“As an Admin User, when I click on the Logout button from the Admin backend while logged in then I will see an “Are you sure you’d like to logout?” dialogue box which I will need to accept before being logged out.“
“As an End User, when I am entering search terms into the search bar I am offered auto-completion suggestions of the words I’m typing so as to make my search experience faster and easier.”
More recently, after reading the book Clean Agile by Robert C Martin (Uncle Bob), we have started using the concept of GWT or Given, When, Then instead of User Stories.
We find that GWT has a number of advantages over user stories:
- GWT can deal with a more diverse set of functionalities than user stories more easily.
- GWT lends itself better to considerations of acceptance tests than user stories.
A more diverse set of functionalities:
Typically we find that user stories fall short when it comes to describing tasks that are centred around developer enablement over direct user features. Say for example that we need developers to work on some continuous integration tasks. They are going to update the deployment scripts so that they deploy to the staging server more quickly. In the user story world, how would you write that?
“As a developer I can…? ” looking at this from their standpoint?
” As a user I will see…?” looking at this from the effect to the end user? Is there really one?
We could always bludgeon the need into the shape of a user story, and in my experience that’s typically what happens. We could also abandon user stories – for the purpose of developer enablement tasks – I’ve also seen this quite often.
If we use given, when, then – we have a common framework, no matter the task.
Examples of Given When Then
That we want to get our work onto staging more quickly for demo and testing.
We run our deployment scripts.
They ought to build and deploy in under 5 mins.
Without any compromise (or “bludgeoning”), this set of descriptions perfectly captures the needs of the ticket.
If we look at the previous user story we could GWT it as:
That we want our admins to not log out accidentally.
They click on logout from the admin backend.
They should see an “Are you sure you’d like to logout?” dialogue box which they will need to accept before being logged out.
A better consideration of acceptance tests:
User stories are structured in a manner that considers the end user, and while that is incredibly important and results in more user-centric software, the format doesn’t lend itself well to covering all of ones bases by default.
Given, when, then can also (and should) be user focused, but they come with the additional ability to cover more bases for the behaviour of a feature more naturally.
To expand on our previous example:
Given – That we want our admins to not log out accidentally.
When – They click on logout from the admin backend.
Then – They should see an “Are you sure you’d like to logout?” dialogue box which they will need to accept before being logged out.
And – The dialogue box should fade in and out.
While one can, and should, use “Acceptance Criteria” to express additional functionality requirements; key aspects of functionality can easily be appended to the GWT framework without feeling forced as it often can be with user stories.
This inherently makes the “story” more easily testable, either by user acceptance testers or in automated tests. It makes signoff simpler, more intuitive and as a result, delivers better software in my experience.
In a follow up article, I’ll tackle “acceptance criteria” in more detail and provide a series of more concrete examples on Releases, Epics, Stories, Tasks, Subtasks and how we structure our projects.
Let me know in the comments if you disagree with me please!