How Do You Split User Stories in Agile Scrum like a Ninja?
Intro - How to Split User Stories
In the last 16 years, the Agile Scrum methodology has established itself as the top gun in the software development industry. About 71% companies today rely on Agile instead of the older techniques to get things done.
With its streamlined & meticulous processes and emphasis on modularization (User Stories), it has made the software development a more organized task.
Each User Story consists of a feature or functionality that the development team works to implement, in order to address a need of the client.
Let’s look at a few questions that most people are curious about when it comes to splitting the user stories:
What is splitting User stories in Agile Scrum?
Splitting of stories is very much like breaking down a big task into several small tasks. One big story is broken down into several smaller child stories that each play a role in the overall development.
Splitting should be done with the intent of delivering value to the client & making the development process relatively easier.
This is best achieved by writing child stories which target a capability of a feature. A feature is in itself a working unit that can function on its own, and as part of the bigger product. This translates to real and tangible progress for the product and the team. It also means that the team can quickly develop and test, and get feedback on it from the client.
From the development team’s perspective, the thumb rule is to split stories in a way that every sprint has a piece of feature/functionality that can be developed and tested properly.
2. What is Horizontal Splitting?
This approach involves splitting the story in terms of architectural layers. This implies that the entire story would be split on basis of work belonging to different teams: D.B, Front-end/U.I, Back-end, Security, etc.
This kind of splitting results in a situation where the customer can’t have anything useful or worthwhile to go with until everyone working on the different layers finish their respective share of work.
Development involves coordination of different teams (and people) handling different architectural layers. This approach jeopardizes the value& the process, if one team delivers their share of work, but the other doesn’t.
A working feature or functionality requires all layers to be working in tandem. If development is done layer by layer, there is an increase in the overall complexity. Unless one layer is ready, integrated and working fine with the other layer, testers can’t really test anything, thereby creating latency.
What is Vertical Splitting?
This approach to splitting revolves around splitting the entire story into several doable features or functionalities.This results in child-stories which when implemented, work to deliver some tangible result that’s valuable to the client.
A sprint’s worth of work creates substantial value to the client and helps the team in form of feedback that they can use to improve the functionality.
This is argued to be the best way to move ahead, since it implies that with time, the development team is creating usable functionalities or features. These work independently to get something done, and eventually integrate into the system to work with other such functionalities.
This improves the cohesiveness between different members of the development team, because they are all working on things that together contribute to the output. Also, it’s easier for them to coordinate in terms of how their respective share of work integrate.
What is splitting by business rules?
This approaches the splitting exercise based on the business motives/results that a client wants to achieve.
It works as a function of how much time it would take to get something done, and how important it is to the business of the client to get it done. This helps in deciding what’s the most important & urgent requirement, and what can be handled later.
Example: A web-store owner who ships cutlery will have different business rules needed to be implemented, such as:
- Customers should be able to pay through different payment options: Credit card, E-wallets, etc.
- Every order should automatically create a dossier with shipping information of the customer that can just be printed and attached to the parcel.
Out of these, the more vital need of the business is to be able to accept most payment methods. This ensures that customers wouldn’t be deterred from making a purchase just because their payment method isn’t listed.
Meanwhile, the slip of the shipping details can easily be created manually.
What is splitting by data Types?
The parameters being accepted and the data types being returned drive the splitting process in this case. Depending on the priority of the data types and parameters that are being handled by the system, the priority of the child-stories is decided.
Thus priority is decided by evaluating which datatype is the most value-deriving in nature and hence most important to the client.
A story that does similar operation using different data types can be divided into child-stories that individually address each datatype. This way, features can be built-up incrementally to work with more and more kinds of data.
A highly-preferred approach in this splitting strategy is to first integrate data types that are the easiest to process and are used most often, and then with time, build out to include the more complex ones.
Conclusion - Splitting User Stories
We’ve discussed few of the most important & widely used splitting techniques in the industry. You have been presented with some different techniques to make this happen.
It now comes down to you, to decide which method is best for you. Before you go, lets tackle another related topic that has many Agile fans attentions:
Agile User Stories vs Use Cases: Which one is Better?
So, Agile User stories vs Use Cases: Which one is better?
Before we answer this, we'll discuss and explain a little bit more about what these approaches entail as well as the difference between the two. First and foremost, User stories are not the same as Use cases.
User stories and User cases are not interchangeable. Both have their identified users and both have their own described goals, however, they serve very different purposes.
A User Story largely dwells on the results and benefits of the certain thing you're describing while Use cases are usually more granular and are centered on describing how the entire system will act.
User stories usually start off pretty similar to Use cases in the sense that they are goal oriented, each has its way of describing how the system is to be used, designed with the user's perspective in mind and uses the businesses natural language.
User Stories In Agile
A User story is basically a small note that records what a user needs or does while they are at work. Each User story usually contains a written short description derived from the user's point of view in their natural language.
The main focus of a User story is to concentrate on the user's needs and not the expected results of the system.
It runs on a 3C's concept. The 3C's is a reference to the three vital aspects of what make up a good User story. These days when people are talking about User stories they're basically referring to a User Story that is made up of these 3 critical components mentioned below.
- Card: User Stories are usually written as cards. Each card consists of a short sentence that has just enough content to remind all concerned what the stories are all about.
- Conversation: Continuous conversations between development team members and customers throughout the whole agile software project are how requirements are found and then refined. Important decisions and ideas are usually recorded and discovered during stakeholder meetings.
- Confirmation: This is the User stories' acceptance criteria. During the requirements discussion, the customers confirm to the analyst under what circumstances and conditions the software would be rejected or accepted.
What is a Use Case
Ivar Jacobson introduced Use Cases more than twenty years ago. Their main goal is to capture the point of view of the user while describing the system's functional requirements.
This basically means that it describes all the ways the end user wants to use the system. Use cases capture and record all the ways the system and user can interact in order for them to achieve their goals as well as capturing all the variables that could go wrong.
There are various model elements that make up a Use case model system. The most important of them being the Actor, the Use case, and the relationship had between the two.
Use cases normally have detailed specifications. A specification in Use case is a textual description of the systems' functionality. It records Actor-System interaction. This means that it records system responses to user interactions.
The Acceptance Criteria In User Stories
A User story isn't all just about a single sentence affair. An Acceptance Criteria is also drafted by the product owner with the objective of defining User story boundaries as well as the confirmation of when a successful story has been completed and is working as it was intended to.
Let's take this as your user story example: "As an attendee to the conference, I want to be allowed to register online, so that I can cut down on paperwork and register quickly ". The Acceptance Criteria could probably include:-
- Registration databases have stored the information found on the form
- Mandatory fields must be completed before a user can submit their form
- Spam protection is working
- Credit card payments can be made
- Users receiving acknowledgment emails after successfully completing and submitting their forms.
Pros and Cons of User Stories
The Pros: Future of CIO state that a User story is an informal process kick-started by a simple sentence. Those of you that have the desire to add small increments of value, sooner rather than later, in agile, will find user stories to be extremely helpful.
It's not mandatory that the Use story be simple. Using Use stories that operate at a high level will add a little more to your productive planning sessions as well as a different way of adding last-minute functions to your software project.
The Cons: One of the most obvious disadvantages when using User story in Agile is that they usually leave out a ton of details because they rely too much on the conversational method of relaying time and details of development. The documentation is normally not complete upfront which can prove to be very time consuming
Pros and Cons of Use Cases
The Pros: The Agile Machine believes that formalized concepts are slowly phasing out Use cases. Some of the concepts provided when using Use case in agile include; ability to break down problems into subdomains and identifying actors.
In addition to all this, Boost notes, upfront research that is sometimes required in Use cases can prove to be very helpful to the entire project in general.
The Cons: The fact that Use cases provide such formalized outlines of the project means that they often don't offer much room for project additions and negotiations. This is one of their biggest disadvantages.
Conclusion - User Stories vs Use Cases
All in all, they are both quite impressive. Having knowledge of both these systems may prove invaluable. When you start getting the sense and begin to understand the difference between
Use cases and User stories, you will know what purpose each of them, individually, can serve on your agile project. If your the type that only works with User stories or the one that only uses Use cases, maybe when the next project comes along, after you have completed your planning and risk poker, you can use both of them and see how that works for you.
The better one really depends on what you're working on as well as what you're really planning on achieving.