Themes, Epics, and the Art of Writing User Stories

User stories are as critical and essential in the Scrum world as the required documents in the traditional Waterfall world. Even if we try to avoid the controversial comparison, the need for both is unavoidable. Please note the Scrum guide doesn’t talk about the user stories or user stories examples. 

So, the very definition, scope, or constraints of user stories are open to interpretation and the subject to be improvised. Though the widely popular and acceptable understanding of user stories is that- User stories are the requirements told from end-user perspective to capture the description of a product feature. Go for the best Agile certifications and master Agile methodology to innovate and progress.

What are Themes, Epics, and the Art of Writing User Stories?

An epic is a large story that is comprised of potentially smaller stories for implementation. The stories in an epic have a common objective. And thus, it often makes more sense to simultaneously deliver all user stories of a single epic.
Theme is even a bigger brother of both epics and user stories. The focus area of a theme is generally at an organizational level.

A follow-up question may be– Why don’t we document all requirements just as stories?
The answer is – the Size. It is difficult to document organization-level requirements as stories. It is also difficult to implement requirements that are as big as epics. Thus the requirement capture goes as Themes -> Epics -> Stories.

While the implementation adds up as Stories -> Epics -> Themes.

Writing the user stories is what we are going to focus on more in this article. ‘Why’ we need user stories, we assume is obvious to many. The ‘how’ part is what we will talk about.

User stories can be horizontal slicing of product features or vertical.

Horizontal slicing breaks down the stories by the type (/component/technologies) of the work. While vertical slicing breaks down the stories by the business features. So, if we are making a shopping portal, the horizontal slices are stories based on the backend, integration, UI, or testing functionalities. While vertical slicing would be driven by business features like login, checkout, payment, etc.

Let us take the analogy of cutting a birthday cake. Horizontally cutting will give you either the base cake or frosting or fondant decoration. While a vertical slice will be everything but of an eatable size.

The horizontal breakdown is never a good idea with Scrum (nor while cutting a birthday cake). The reasons are:

1. It doesn’t fit well with the definition of done. Even if you have delivered a backend story or a UI story, it is not a testable, working, or deployable feature.
2. There are interdependencies among the pieces as they can be tested only after they are stitched together.

Let us take the scenario of an online shop selling art supplies. We will have standard business features like:

• Login
• Registration of users
• Adding items to the shopping cart
• Payment
• Logout

So if we write-“As a user, I should be able to check out the items I have added in my cart”, this is not granular enough to implement. This is our ‘epic’.

Our User Stories can be;

“As a first time user, I will be asked to either register or purchase as a guest user when I check out the items I have added to my cart”. “As a registered user, I will be shown the items added to my wish list so that if I want, I can add them to my cart when I check out”

If you feel the stories are still vague, the user stories can be more detailed by adding “conditions of satisfaction”. And if needed, they can be split into multiple, smaller user stories.

How do you Write an Epic and User Story?

1) Size

Since the Scrum Guide doesn’t talk about user stories, there is no standard rule of how big (or small) a user story is meant to be. For all practical purposes we know – it has to be small enough to be delivered as a part of one sprint. With a better understanding of Scrum and team dynamics, the team gets better at estimating the size of a user story or how many stories they can accommodate in a sprint.

2) Perspective

User stories are always written from the perspective of an end user (or customer).  So the widely used template is: As a < (specific) type of user >, I want < goal/business feature > so that < reason to validate the goal/business feature >

3) Author

It is the product owner’s responsibility to ensure the product backlog of Agile user stories exists. However, it is not of much importance who actually is writing those stories. In a happy scenario, all team members should be capable enough to write user stories.

4) Simplicity

Like any English statement, a simple, readable and easily understandable statement is the want of one and all. The best stories are the ones that leave no scope for ambiguity. Write your stories so that they are easy to understand. 

Keep them simple and concise. Please note – user stories should include the format- who-wants what-why. The ‘how’ shouldn’t be included. ‘How’ is the technical implementation part, better left to the teams to decide.

5) Readiness

The user stories have to be granular enough to be taken up by the team to implement. One has to keep refining the stories until they are ‘ready’ (to be implemented). Break down the epics into more implementable size stories. Another aspect of readiness is that team has a shared common understanding of the user stories of the current sprint.

6) Accessibility

Keep your stories visible and accessible to the team. The product backlog is an evolving artifact and explains the product vision. The team needs to be aligned with the product vision. Thus, access to the product backlog and the user stories helps the team with the implementation and sprint planning. 

One quick way is to put up the user stories of the current sprint on a wall. Sticky notes, posters, paper cards, whatever works with the team. This fosters collaboration and creates transparency.

7) Beyond Stories

So far we have talked about what user stories are, how to break them down, and the tips and tricks to write better stories. Yet in the end, I am asking you not to rely completely on user stories.

Get ready to ace your project management exam with our project management exam prep class. Gain the essential skills you need to succeed and elevate your career to new heights.

Conclusion

A great product needs more than stories. A user story is a great tool to capture business features or product functionality, but it cannot help much with user journeys. An assisted visual journey using story maps, sketches, mock-ups, and workflow diagrams helps the team further to understand the overall flow. Get leading SAFe certification training and learn to scale Agile across multiple teams.