An Introduction to User Stories & Epics

“Storytelling is the most powerful way to put ideas into the world today.” – Robert McKee

I’ve previously covered in some depth the subject of requirements: the different types; the scenarios; why, where and how they could be identified and elicited; the owners and how to manage them. We looked at how important they are to the successful delivery of products, processes and projects (who doesn’t love a little alliteration?) and the differences in project delivery methodologies which impact the way requirements are gathered and managed.

When using an Agile approach towards project delivery, especially for developing or adding new features to software, traditional requirements may not be the best tool for the business analyst to employ. The technique often has a criticism leveled against it that traditional requirements are somewhat monolithic in nature, given their at times rigid approach and fixed nature. Agile development requires an iterative approach, needing a flexibility which is not always inherent within a detailed traditional requirements approach. To aid this, business analysts can use the technique of creating user stories.

User stories are a way of capturing a need, a feature or a scenario through a more abstracted approach towards producing and defining a narrative for requirements. Essentially, user stories ensure that descriptions of features are written in a way that is simple, more natural and easier for customers to understand by crafting them into succinct and structured statements. User stories are usually written from the perspective of the main actor in a process or systems environment, who is often the end user. The abstract nature of user stories often complements use cases which might be defined early on in the Discovery and Analysis stages of a project, and help to define the features to be captured as part of the solution design.

User stories can be written in a dedicated tool such as Jira or Microsoft DevOps, or on something as simple as index cards or Post-it notes. What’s important is that we capture the user stories in a structured and controlled way, and that they become a trigger point for further discussion around the features that the user or users wants to see delivered.

Structuring your Story

As with most business analysis techniques, there are variations in how a user story might be captured, but there are several common constituent parts which they consist of:

Actor: The ‘who’ in the story – this is usually the end user in the story, but can be any entity or persona which the business analyst identifies as having an interest in, or being impacted by what is being defined. Always forms the start of the User Story statement, and can often take the form of “As a user…”

Action: The ‘what’ in the User Story, this describes what is actually happening or the goal or desire for the actor in the solution. Often prefaced by the syntax, “I want to be able to…”

Outcome/After Effect: Describes the ‘why’ or, more accurately, the “so what” in the user story, and outlines in detail what the desired benefit of the requirement is for the actor/user. This is the condition of satisfaction that indicates whether or when the requirements described in the user story have been successfully met.

In practice, this might see a user story constructed like this:

“As a Credit Control Analyst (Actor/User), I want to be able to receive daily expense reports (Action) so that I can complete reconciliation of company expenses (After Effect/Outcome).”

User Stories can be broken down into lower levels of granularity as required by the BA and/or Product Owner to get the detail needed for the feature or solution. Expanding on our previous example, we might see something like this:

“As a Credit Control Analyst, I want to be able to see individual Cost Centre codes in daily expense reports so that I can recharge expenses back to individual departments.”

Alternatively, you might add some comments and notes to the user story to flesh out the details of what the feature is. You can validate the user story with your customer and developers to make sure that your design is still on track and confirm the scope you’re working within.

Making it Epic

I’ve mentioned how detail driven out in the user story can be scaled down to capture additional detail but conversely, it can also be scaled up into a higher level of abstraction. In a similar way that traditional high-level requirements can outline the ‘big picture’ using broad brushstrokes, capturing user stories at this level can be used to set the scene for the requirement being defined at lower, more granular levels. This classification of user story is termed an ‘Epic’, and Epics usually have several related User Stories nested under them.

Using our previous example based around a Credit Control Analyst, our Epic might be structured as follows:

“Produce reports for Credit Control.”

Epics of a similar subject can be grouped together in a product backlog under an overarching grouping for clarity and simplification. This is the highest level of abstraction and the statement is called a ‘Theme’. An example of a Theme might be:

“Produce company reports”

Themes and Epics are neat ways of organising and structuring user stories in a logical and controlled hierarchical manner. They’re a means to an end though, and we shouldn’t be expected to try to force user stories and Epics into existing hierarchies and/or groupings for the sake of it.

The focus so far has – quite rightly – been on Agile delivery, where user stories naturally find their home. However, BAs can make use of user stories in Waterfall projects, where it can be used during the Discovery phase to prompt expanded thinking around the problem and solutions by business users. There’s an argument to say that user stories fulfill a requirement that’s more suited to brainstorming and use case analysis for waterfall delivery, which possibly has some merit. However, there’s no definitive rule that states that user stories can’t add value to the project. As business analysts, we should use our professional judgement in selecting the right tool for a given situation, even if that sits outside of the well-established box for a given project methodology.

Keeping Control

Like their more traditional requirements counterparts, user stories should be managed throughout the lifecycle of the project to ensure that they are accurate, timely, and most importantly, still needed. The simplified nature of the syntax used in user stories means that particular effort needs to be given to ensuring that what’s been captured is actually what’s been asked for. This is especially important when developing user stories for technical solutions.

User stories and Epics will usually be managed in the product or sprint backlog by the Business Analyst and the Product Owner – note that the two might actually be the same person / role! For clarity, anyone involved in the project, team, or any business user can develop a user story, although the BA or PO will usually be responsible for the ongoing maintenance of all documentation.

An effective means of managing user stories is through the use of Kanban boards. As the user story or Epic is progressed through each sprint iteration, they can be stepped through the defined stages on the Kanban board until completion. Of course, using a different methodology will require differing controls for managing the stories/Epics. This is particularly applicable where user stories are used in a Waterfall implementation – rare as that might be!

Once the user stories have been formally captured, they can be discussed and agreed between the project team and the business. User story validation will lead to being able to baseline and develop the required solutions. They can then be managed through the Product Backlog or the repository in line with project standards. When they are complete, the user stories, their revision statuses and any comments should be retained for audit and governance control purposes.

Summary

User stories and Epics are a very useful technique for driving out understanding around solutions from users. They are complementary to requirements and use cases, instead of being an outright replacement for them.

In the right environment and contextual situations, they are really helpful for prompting discussions and an excellent guardrail for getting the business to know what they’re asking for.