Introduction
User stories are single line requirements in the form of a story of what an end user wants and why. An ideal user story format followed by the industry is “As a , i want , so that . The reason why agile requirements are in the form of user stories is fairly simple – we need to get feedback from the users and we need to get the feedback as early as possible. However, when it comes to a practical scenario, teams tend to pick user stories which are too big to deliver or even showcase in a sprint.
There are a lot of practical antipatterns when it comes to writing stories and implementing them.
Are your teams doing any of the below mentioned points in your sprints?
- Stories getting spilled to the next sprint because it is too big?
- Taking tasks from big stories to fill the capacity of the current sprint but committing to deliver the story in a future sprint?
- Dividing a story and creating a story based on skill set? (Development story, backend story, frontend story, testing story etc)
If yes, you have landed on the right page, because this blog aims at explaining
- What is a User story and what are its characteristics?
- INVEST story writing
- Vertical and Horizontal slicing of a user story
- Why do we have to split a user story into smaller pieces?
- Some sample techniques to split the story with examples
What is a User Story?
A User Story is a simple/brief one line requirement written in a simple language from a customer / user’s point of view. It has 3 parts to it
An Ideal user story is in the form of “As a , i want , so that < What is the purpose?>
Examples
- As a , i want to , so that
- As a , i want , so that i can
Characteristics of a User Story
A user story is a requirement which
- Always has a business value associated with it. There are always reasons why a requirement is born, it can be based on consumers feedback, competitive advantage or to generate more revenue.
- Will Help teams get feedback. A user story , when converted to a software should always present itself as a point which can get feedback as quickly as possible. Feedback can be of different levels, is it what my consumer wants? Is it how my consumer wants? Does this add value to the product?
- Triggers a conversation. A user story with enough information should trigger a conversation between a PO and the development team. There has to be common understanding between the teams and the POs in terms of what the PO wants or what the teams need to develop. And user story is the starting point which should trigger a conversation
- When Delivered, it is usable by someone. Delivering an API or a UI screen or writing a login will not help teams to get valuable feedback from a business standpoint. So a user story has to be written in a manner that there is something usable by the end user when delivered
- Is an Increment to your product. Since agile is a incremental and iterative model, a user story when delivered adds up to the product list of capabilities when delivered
INVEST Story Writing
Writing a good user story comes with a lot of practice and experience. However, INVEST is one of the most recommended techniques for writing a user story. A PO has to keep in mind the below mentioned points while writing a good user story
- A User story is INDEPENDENT of other stories. A story can be worked upon in any priority in the sprint. We should not rely on finishing a less valuable story to start more Valuable story
- A user story strikes a conversation between the teams and the stakeholders. Scope can be NEGOTIATED by the dev teams and product owner
- A user story is VALUABLE to the end user or the business. When the user story is delivered, user can give feedback or the company can see some business improvements
- A user story has enough details so that the development team can ESTIMATE
- A user story is SMALL enough to be tested and completed in one sprint.We will not wait for 2-3 sprints to get feedback
- A user story is TESTABLE to check with completeness of the sprint
Breaking / Slicing a User Story
Checking if we are in the right direction and changing based on the needs is one of the main idea behind agile ways of working. And one way to do that is to get constant feedback from the customer, consumers or the product team.
We understand that the requirements come in various sizes. Some requirements are small and some are big. Smaller requirements take less time to deliver and get feedback. But the Million dollar question is “how to get feedback for a big requirement which will take a lot of time to deliver?” and the answer is to break the requirements (User stories) into smaller requirements (User Stories) and deliver it continuously.
Why do we have to split user stories into smaller pieces?
Simply because it is too BIG!!! But also,
- The story is so big that we cannot deliver it in one sprint
- It is too complex and complicated. It might have too many steps and may be difficult to test
- Smaller stories when completed gives the teams sense of accomplishment
- We might not have all the information about a story. We might as well finish the part of the story which we know and get it done
- Not to get stuck!! Smaller stories help teams get feedback and helps in consistent delivery
Horizontal and Vertical Slicing of User Stories
This section talks about one of the important aspects of breaking a big user story into smaller stories. Imagine a big story which needs to be broken down into smaller stories, and this story needs Backend logic, API development, Frontend development and testing as depicted in the picture below. Also, let’s take a sample user story as mentioned below,
Sample Story : As a consumer, I want to login, so that I can place an order from the system. Now this story will need backend logic to be written, API to be developed, UI to be developed, Integration of API with the UI and then testing
Acceptance Criteria:
- Login must happen for valid credentials
- Error must be thrown for invalid credentials
- Password must be case sensitive
- Password must be 8 letters long and must contain 1 number, 1 special characters
Horizontal Slicing is breaking the story with respect to the layers / skillset. We have observed many teams practicing this method where the story is broken down into smaller stories but technology wise. In this case the above mentioned user story will be broken like
- Story to write backend login
- Story to prepare API
- Story for UI development
- Story for testing
This is a bad practice and not recommended because none of the 4 stories (Mentioned above) is testable and releasable. UI alone or API alone when developed cannot be released to the end user / PO to get feedback
Vertical Slicing is breaking the story with respect to the capabilities/functionalities/operations rather than any skillset. In this case, the above example story can be broken down into
- As a user, i must be able to login with valid credentials
- As a user, i must be able to see error when i try to login with invalid credentials
- As a system, i must validate for password length
- As a system, i must validate the password condition
In this case, all 4 stories can be individually developed, tested and delivered to get feedback and we have broken 1 big story into 4 smaller stories which can be quickly developed and helps the team to get feedback.
Techniques to Split User Stories into Smaller Stories
There are several techniques followed by different teams to split a big user story into smaller user stories. Below are a few mostly used techniques which we recommend strongly to use for splitting stories.
- Based on User Roles/Personas: If your story is too big and multiple roles are involved in completing a transaction, it is better to split the stories as different roles / personas contribute differently
- Based on workflows: If a story has multiple actions / steps , one way to break the stories is to create stories for each action.
- Based on Platforms: If the product is catered to users with different environments, you can also break the stories with respect to platforms, web browsers, operating systems
- Based on CRUD Operations: If a story involves Creating, Replacing, Deleting, Updating of a data set, best way to divide it is with respect to the operations involved
- Based on Acceptance Criteria: One of the first options and the simplest ways to break a story is with respect to the acceptance criteria. A classic example shown in the image above and also in the Sample Story ( Vertical Slicing )
- Based on Data Types: A story involving different data types can be broken down into smaller stories for each data type. Multimedia upload can be broken down into photo upload, video upload, audio upload( Just a sample )
- Business Rules: If you are developing a feature which behaves differently in different regions, or the behavior is rule driven, then you can also break the user story rule wise
Conclusion
There are several ways / techniques to split a user story into smaller pieces. You can use one of the above mentioned techniques or even mix and match the techniques. The intention is to break the stories logically which can be developed, tested and delivered so that we can get quick feedback.
This brings our blog on “User Stories & Techniques to split it” to a conclusion.
Please reach out to “consult@benzne.com” for any suggestions or feedback.
Sujith G
Agile Coach – Benzne
