User stories are as critical and essential in the Scrum world as the requirement 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.A follow-up question may be –
Though the widely popular and acceptable understanding of user stories is that-
The user stories are the requirements told from end-user perspective to capture the description of a product feature.
So, what are epics and themes?
An epic is a large story which is comprised of potential smaller stories for implementation. The stories in an epic have a common objective. And thus, it often makes more sense to deliver all user stories of a single epic at one go.
Theme is even a bigger brother of both epics and user stories. The focus area of a theme is generally of an organization level.
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. And 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 more in this article. ‘Why’ we need user stories, I am assuming is obvious to many. The ‘how’ part is what we will talk about now.
User stories can be horizontal slicing of product features or vertical.
Horizontal slicing is breaking down the stories by the type (/component/technologies) of work. While vertical slicing is breaking down the stories by the business features. So, if we are making a shopping portal, the horizontal slices are stories based on backend, integration, UI, or testing functionalities. While, vertical slicing would be driven by business features like login, checkout, payment etc.
Let’s 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.
Horizontal breakdown is a never a good idea with Scrum (nor while cutting a birthday cake). The reasons being:
- 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.
- There are interdependencies among the pieces as they can be tested only they after they are stitched together.
Let us take the scenario of an online shop to sell art supplies. We will have standard business features like-
- Registration of users
- Adding items into shopping cart
So if we write –2) Perspective
“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 in my cart”
“As a registered user, I will be shown the items added in 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 made more detailed by adding “conditions of satisfaction”. And if needed, they can be split into multiple, smaller user stories.
Additional considerations for writing good user stories:
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. By all practical purposes we know – it has to be small enough to be delivered as a part of one sprint. With the 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.
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 of not much importance who actually are 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 of 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, to the more implementable size stories. Another aspect of readiness is that team is having 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 the access to 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 talked about what are user stories, 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.The reason is simple.
A great product needs more than stories. User story is a great tool to capture business features or product functionality, but they cannot help much with user journeys. An assisted visual journey using story maps, sketches, mock-ups, workflow diagrams helps the team further to understand the overall flow.