A Decent User Story
User Story is an almost ubiquitous form of requirements these days. Some organisations still write BRDs and FRS (large documents about functionality), but these are exceptions. The world has by far moved onto user stories in some or other form and is for good.
When I started, I used to write stories only with Acceptance Criteria which was in the form
xxx should be able to …
xxx should not be able to …
Over a period, I got wiser and better structure emerged.
Sometime back, I wrote this blog on identifying a unit story with user perspective. Here I intend to discuss the structure of a user story which has worked for me and the teams I worked with.
My initial days of story writing, the team often told me that I am writing too less or they are not clear on what needs to be done. A little bit of analysis and had a realization, I was writing stories with only business teams in mind. A User Story, while it is called so, is not for end users or a business team or BA alone. Tech Team is a key consumer of this artefact, and It is essential to keep the developer and QA in a frame of reference. This doesn’t mean elaborating a story in technical terms or dictating every detail of implementation but ensuring developers don’t find it’s a strange tale.
A story needs to communicate
- Where does it fit into a big picture and
- Be granular enough for developers to implement it with reasonably clear expectations
All of this might sound a bit too much to achieve in 10–15 lines but with some structure achievable.
My typical story when elaborated would include few or all of the following sections
1. Narrative
2. Assumptions
3. Acceptance Criteria
4. Out of scope
5. Questions
6. Key Scenario / Data
7. Reference to wireframes or business rules if applicable
Let’s understand a little bit more about each section and what it does
Narrative
The Internet search for “A User Story” gives articles pointing to a narrative.
The narrative is nothing but a short sentence in the for
“As a <type of a user> I Want to <activity/goal> So that <reason> “
At first glance, this may seem dispensable when you are into thick of a delivery cycle, and multiple developers are working to produce “Asked” software.
However, this is one of the most important blocks of the user story if not user story itself. It provides the objective of the story, why this story needs to be developed, what user will achieve. It also helps BA to elaborate the scope of the story as often “So that…” encompasses broad objective but practically everything is not needed. It helps in developing an understanding of what is needed and shapes up Assumptions as well as out of scope details.
Assumptions
It is essential to call out assumptions being made for the story. Assumptions could be about the availability of other systems or dependencies or even user behaviour which has led to the situation. This forces all stakeholders of the story to think about the situation and the value of the story holistically. Some of the assumptions are very implicit in the business or tech world. It is important to call them out so that remaining stakeholders are aware of it and surprises are avoided. In my experience Assumptions have immensely helped in channelised QA and UAT effort and catching up blind spots.
Acceptance Criteria
Acceptance criteria mention what user would get when the story is completed. There are two dominant styles of writing ACs,
Given … When … Then
eg. Given that I am a logged in user and on a Home Page When I goto my profile I See my communication details along with address and preferences of notifications
User should be able to …
eg. A user should be able to see communication details, addresses and preferences in the profile or User should be able to navigate to profile from a home page
Acceptance Criteria is usually a closely watched space in the user story.
Out of Scope
As systems get elaborate and sophisticated, dependent stories are a reality. There are dependencies and are more intertwined than we hope for. Calling out what is not in the scope for that story protects the story from scope bulge. If a particular part is covered in another story, cross-referencing it can bring up connected backlog very neatly. Out of scope items can be listed as simple bullet points without any conditions.
Questions
Typically as a BA, we would make stories ready for analysis/validation from devs few days in advance of actual development(if running sprints, then a sprint earlier). The story can then be analysed by Devs & QAs offline or in a quick meeting. It’s a good practice to capture this discussion in the story. Questions section helps in recording such conversation here so that anyone who picks up the story for development gets the context.
Key Scenario/Test Data
As systems get developed, multiple pieces are stitched together, building a litmus test for success criteria is important. In case a story has integrations with other systems or is responsible for writing complex logic, provide litmus dataset for quick validation. As BA one would have any way used such data during analysis, making it available to for everyone will save a significant amount of time during Dev validations and QA.
Wireframes/Visual Designs
Based on the context, information and time we can also add wireframes/visual designs/business rules in the story. Having details right in the story reduces the chances of missing vital information as one doesn’t have to search through multiple sources of information to understand expectations.
Depending on teams maturity shape and details of stories may change. Sometimes with very business savvy developers, even very limited information in a story you could get a fantastic outcome. But is not always the case.
I prefer every story to contain the initial four sections at least so that both technical and business stakeholders understand story expectations and are clear about the expected outcome of the story.
Once the story is developed and signed off, the user story has negligible value as underlying code is continuously changing. Robust automation test suite is the only tool for ensuring what was developed earlier continues to function as expected.
