Introduction
When we think of software development and programming, we envision someone building or implementing something. However, before we rush to our keyboard and start creating magic, we need our requirements (which should come from the appropriate stakeholders) clearly and effectively documented. Our recommended method for documenting requirements is User Stories, and when written well, User Stories allow us to describe the outcomes we want to achieve and what we must build to achieve them.
The importance of writing a good User Story cannot be overstated. The difference between a well-written and poorly written User Story can determine whether a requirement (or outcome) is met. A bad User Story can lead to revisions or rework that can be costly in terms of time, money, and lost opportunities. If you write bad User Stories, you risk delivering poor outcomes. Thinking about 'outcomes' should be at the heart of any User Story creation and review process. It all sounds pretty doom and gloom so far, but as the saying goes, “It’s not rocket science”. By understanding the core principles listed below and applying them consistently, you’ll be equipped to write stories that increase your chances of successful implementation, equipping you and your team to deliver the outcomes that matter to your stakeholders.
Story Anatomy
At its most fundamental level, a User Story must explain the outcome that 'someone' (a persona) is trying to achieve. As a ServiceNow professional, your task is to help deliver this outcome. Your story plays a part in delivering the outcomes that will make your stakeholders happy. The story may be a unit within a larger epic or outcome, or it may describe the full outcome itself. Either way, this should be clear when you read a story. If it's not, consider how you can make it so.
If you’re a fan of snazzy acronyms or want to distil the essence of a good user story, the I.N.V.E.S.T model can help you structure your user story.
Independent
Negotiable
Valuable
Estimable
Small
Testable
Whilst I personally do not use this model, having this in the back of your mind when you’re creating or reviewing a story can often highlight areas where elements of this framework are not being met, meaning more work on the User Story is needed.
Different people may have different styles of writing a story, but in my opinion (and many others), there is one to rule them all, and that recommended method is:
AS A, I WANT, SO THAT (Story Description)
GIVEN, WHEN, THEN (Story Acceptance Criteria)
A good user story description states the who, what, and why of the overall requirement. Who is involved, what do they want to see happen, and what outcome will that give them, or should be observed. This should be written in plain language and concisely describe what the persona wants and needs to deliver the outcome.
AS A [Persona] -> State and describe the typical user or persona this requirement is being stated for. The user who should be observing the outcome.
E.g. AS a Major Incident Manager responsible for triaging P1 at a Bank
I WANT -> Describe the intent of the persona, what are they trying to do? This, ideally, should be delivered in non-technical and non-product specific language.
E.g. I WANT to be notified of any potential Major Incident candidates.
SO THAT -> Here we are describing how the delivery of this story contributes to the bigger picture. The outcomes achieved by meeting the requirement may help the persona and/or organisation solve and existing problem, improve inefficiencies, reduce cost, or any other benefit.
E.g. SO that the time the organisation and major incident teams take to react to potential critical incidents is improved, reducing the potential impact on customers, systems, and financial penalties associated with a critical incident.
A good story acceptance criterion describes the various scenarios and behaviours that the persona(s) undertakes to deliver the requirement and outcome stated in the story description. A story can, and usually should, have multiple acceptance criteria.
GIVEN -> State and describe the persona highlighted in the original requirement. This persona is the one involved in undertaking the activities required to deliver the requirement. Typically, this is the same persona as the one in the description. However, some stories may involve multiple personas.
E.g. GIVEN I am a Major Incident Manager or a Service Desk Analyst
WHEN -> Describe the actions that the person will undertake in the scenario. This could include actions like clicking a button or performing a specific task. If there are multiple actions, state them additionally, or consider splitting them into separate acceptance criteria.
E.g. WHEN using the ‘Propose Major Incident’ function available on active incident tickets.
THEN -> Describe the expected response required to deliver the outcome (or part of it) based on the actions taken by the persona. There may be multiple expected outcomes, so list them all. If multiple actions are taken and multiple outcomes are expected, use your judgment to determine if it is more appropriate to split them into additional acceptance criteria.
E.g. THEN I receive an email informing me that a potential Major Incident has been logged and requires review/attention. The email should also be branded using the organisations branding guidelines.
You may or may not be familiar with the method of expressing a User Story. The biggest benefit of this method is that we are writing the story from a persona-centric perspective. Writing from this perspective allows us to understand a persona who represents a real user, in a real role, performing real tasks. If we understand the persona (the user), we improve our chances of delivering the desired outcomes and ultimately achieving customer success.
If you needed more convincing, some more benefits of expressing stories this way include:
Improved speed and accuracy of story estimation.
Positive and negative scenarios can be expressed more easily.
Ability to quickly translate scenarios to UAT test cases.
Stories become developed agnostic and align to industry standards.
Provides path for clear alignment and expectations on what is being delivered between you, and the customer.
Allows both parties to easily understand when a story has been met, and when it has not.
Comments