Everybody on an agile team understands the importance of user stories. It is the simplest unit of work, more like an end goal that defines the success of the team. It is also an important part of the product backlog, another vital determinant of the overall success of the product.
Given the importance of the product backlog, it is essential that the quality of the backlog remains guaranteed. The best way to do this is by splitting user stories. In this article, we will discuss the importance of splitting user stories in the agile structure, popular techniques used to split user stories, and the process of estimating story points with multiple teams.
The main reason for using a user story in the product development process is to show how the product will give value back to the users or customers. It then follows that the user story is similar to the user’s requirements, which must be met before value can be delivered through the product delivered.
Therefore, splitting the user stories refers to the process of breaking these requirements down into smaller and functional units. With these smaller units, you can create a realistic workflow that allows you to perfectly understand the user’s needs and help you ensure the fulfillment of these needs.
Also known as slicing, splitting a user’s story in an agile structure comes with a lot of benefits. Some of these benefits include;
There is a method used to slice a user’s story known as Vertical Slicing. This method allows you to split users’ stories through multiple architectural layers in a bid to ensure that your customers and users get value for the product. With this approach, product managers can avoid the ineffective approach of delivering only the UI aspects of the product, a measure that does nothing to add value to the users.
When user stories are broken down to the nitty-gritty, the members of the engineering team and design team understand the project better. Also, they are able to identify the different features rolled into the single functionality found in the user story. Finally, and most importantly, the team is able to focus on the highest value feature and most important functions while designing and developing the product.
After splitting user stories, the engineering and design team get to work on smaller units at a time. Because of the size of these stories, the features are completed in a few days and the product owner can check them and also give feedback as soon as possible. This makes the development process flow better and result in a useful product for the user.
In the same vein, the fast feedback makes it easier for the engineering team to correct any mistake or error in the feature developed. It is easier for a programmer to remember and correct a code written within 24 hours than for the code written after weeks or months.
There are many techniques for splitting user stories. The technique adopted depends on the framework your team uses. Hence, there is a different technique for users of the Agile framework and different ones for Scrum structure. Some of the techniques useful for the agile structure include;
The INVEST model stands for Independent Negotiable Valuable Estimable Small Testable. Each of the terms in the model refers to how the team can approach the splitting process. For instance, if the user story is Independent that means that you can pick any of the features in the story and develop it in isolation. If the story is Negotiable it means that there is room for giving and take, and the team can add more details to the feature when they have more information.
The user’s story that would undergo splitting must be valuable to both the users and the business. In the same vein, the story must be Estimable and Testable before you can consider splitting it.
One of the widely used approaches on the Agile Framework is the MVP approach which involves the development of the minimally viable product that would deliver value to users. This approach can also be used in splitting user stories. In this approach, the team should opt for the development of the minimally viable feature that would communicate value to the user. For instance, the minimally viable product for a login feature would have the basic UI design, the simple logic, and output built.
Every user story has an acceptance criterion. This criterion defines the business rules for the user requirement. With these rules, it is easy to split the user story along the lines of the requirements. This is because the team now understands the criteria that define the acceptance of the product, and will proceed to develop the product with these criteria in mind.
The same way a user story has an acceptance criterion, it also has happy paths and unhappy paths. Breaking the user story down along these paths makes the development of the product easier. All you have to do is take on the features that belong to the happy path first and complete the ones under the unhappy path after that.
There is usually more than one class of users. This means that there are numerous user personas. Using these different user personas can help you split the user story into function smaller units. This is because different users use the feature in peculiar ways. These ways could be influenced by the type of device used or the operating system used.
For instance, users using Android and iOS would use the features of a product differently. Splitting the story based on the difference could help the team develop a more useful feature for each class of users.
The techniques highlighted and explained above are usually used for the Agile framework. There are also other techniques applicable for teams on the scrum framework. These techniques include the horizontal and vertical splitting techniques.
This includes slicing the user stories along architectural lines, or better put, in a horizontal manner. This involves splitting the story along the interface-logic-database line. As an example, if the user story is “I want a product that allows me to log in to my school portal”, the splitting of this story on the architectural layer would include;
Each of these processes would require a user story which means that the main user story has been split into these smaller units. This approach is very helpful especially for the engineering teams, as they are more familiar with it and this makes it easier for them to work efficiently.
However, the approach is not without its disadvantages. The biggest drawback is the fact that members of the engineering team may leave the process they are not very comfortable with for last. For instance, if the engineering team comprises more developers than designers and are not comfortable with the interface design that comes first, they would likely leave it for last. This would affect the quality of the eventual product as the design is supposed to guide the developmental process.
Another approach to splitting user stories is to vertically slice the story. When you do this, you ensure that each story crosses the boundaries of the architecture, while fulfilling only a portion of the functionality, once at a time. Using the example in the horizontal splitting approach, splitting the user story goes like this;
The major advantage of this approach is that it makes it easier for the users to use the product. It makes testing and feedback faster and easier. With this slicing approach, users can test the product faster and they can give feedback to the team as fast as possible.
Understanding the process of splitting user’s stories is very important in the product development process, as we have highlighted in the article. With the different splitting approaches available, product managers and the overall product team can understand user’s needs better and work towards the development of the perfect product.
2258 Norbury Dr, Smyrna,
GA 30067
5927 Almeda Road, Houston,
TX 77004
4585 Evelena CT Fremont,
CA 94536
50 Bruyeres Mews, M5V0H8,
Toronto, Ontario
Prince Turky Al Awal street,
Riyadh city, Saudi Arabia
1105, Shivalik Abaise, Prahlad Nagar,
Ahmedabad, Gujarat - 380015
288, 21st cross, 13th Main, Sector-7, H.S.R. Layout,
Bangalore - 560102
Quick Links
Subscribe to our newsletters
