User stories splitting, working with epic, epic splitting into user stories. One great art. In the first part, we have shown you examples for splitting requirements into smaller ones by the process. Although this is the last division step for many Product Owners, this is not enough for a reasoned app. In this part, we will take a look at another handy option. By operations.
Hmm, what do you mean by ‘operation’?
Developers are familiar with the acronym CRUD, which indicates operations Create, Read, Update, and Delete. And exactly these operations are the most common example. Others may be e.g., Archiving, Export, Import, Registration, and Login.
Why divide it this way when it is most commonly possible to be programmed at the same time? Because it can be programmed at the same time, it does not mean that we have to publish it at the same time. It does not mean that we have to invest in design and development time in all these operations.
Requirements are not about development. They are about delivery. This includes testing, documentation, marketing, etc. And all of that costs time, money, and resources. Use it wisely.
We may lack all of that for something more important, which the client needs more at a given time. But we can’t give it to them fast enough because it is easier for the developers to do CRUD at the same time. And the most common argument of development is that they won’t be rewriting the task several times. Well, if it’s necessary, then it’s necessary.
Division by operation, e.g. CRUD does not mean unnecessary rework.
Story of comments and user stories splitting
A few years ago, as a Product Owner, I was faced with a decision on what would be possible in the ScrumDesk app with comments. As a developer, my heart was telling me a definite answer. The entire CRUD. We’ll do it all at once. But in a given sprint we had other, more critical requirements. I was looking for space to ‘save’ and put aside less important things.
It was very bad, everything was necessary and critical in the sprint.
At some point, I landed on the user story Comments for the task. Hmm, what about it? After all, the comment must be written and then displayed. The user will certainly want to delete it. And if they make a mistake, correct it. All clear, right?
Maybe not. So I looked at the previous Windows version. I was surprised to find that only a small percentage of the comments were edited. However, many had two frequent operations. Writing and deleting. Actually, it was more of them than editing the comments.
Simply, people instead deleted the comment completely and wrote it again. Weird, right? That doesn’t make sense!
That’s it. I don’t think it makes sense because I have a used pattern. The reality of the Product Owner is always surprising.
So, in the next version, it was possible to add and delete the comment. And I didn’t believe it myself, after a few months it was embarrassing that we couldn’t edit a comment, so I decided to finish the task. Only much later. And in the meantime, we added different features.
Why? Because even with such a simple functionality, you are suddenly opening several more chambers:
- Testing of a minimum length.
- Maximum length.
- Character sets.
- Saving.
- Saving with network outage.
- Overwriting the comment by another person, not the author.
- Overwriting the comment by the author.
- etc.
So it was a small change that brought up many test cases, longer regression text, more code, more errors (empirically said 10 lines equal 1 possible bug).
Netflix
In apps like Netflix, Spotify, Podcast Go, and other players, it is very convenient and easy to split user stories by operations. In the first version, you can only offer playback, pause, and stop. In other versions, fast rewind and then, if necessary, the possibility to skip 10 seconds.
Another opportunity is to sign in or manage your favorite list. An example of a Netflix product backlog by operations is in the map below.
Example of requirements split by operations in Netflix app.
In this user story map, the Product Owner can sort individual user stories and create adequate minimum usable or marketable products. You can publish them, verify how they work and only when it makes sense add more functionality. And maybe people will ask for it themselves, vote for the others.
eCommerce
eCommerce apps such as Amazon have several features that can be used to split user stories into smaller ones. What’s interesting about them is that one functionality has several variants, such as to Buy and to Buy Now.
Other suitable operations may be Add to Favorites, Remove from Favorites, Compare, Vote, Follow. These operations are often identified very early. Even during the brainstorming of functionalities, the Product Owner finds out which functionalities are very essential. At this point already a lot of useless things are eliminated.
Example of split by operation in eCommerce, eshop applications.
If you also thought about developing another eCommerce system, perhaps mapping your requirements in this way will allow you to choose the appropriate, already existing solution.
Banking app
In banking apps, this type of division is suitable for:
- reviewing account status and transactions,
- card operations,
- in operations with given transactions, e.g. exporting, printing, sharing,
- nowadays, modern bank apps allow creating an account and login in through biometrics.
Banking app and requirements splitting into smaller ones according to the operations.
Insurance
Apps in the insurance industry use this type of requirements division when selecting and purchasing an insurance product. In fact, this is already very similar to the division according to the business process but ultimately, it does not matter. The main thing is that the epics are smaller now, right?
Example of splitting by operations in the ScrumDesk application in insurance-related products.
Telecommunications operator: self-care app
Do you use your mobile carrier’s ecare app? Whether mobile or web app, both allow you to perform basic operations with your phone bill, i.e. to buy other products.
- Viewing product status – As an operator’s client, I want to view the status of the product I purchased to know my costs.
- Call History – As an operator’s client, I want to see the call history so I can manage my usage in the next period.
- Call list export – As an operator’s client, I want to export the call list for the current period so I can do a more detailed analysis.
- Product Purchase – As an operator’s client, I need to purchase another product.
Example of division according to operations in eCare app of a telecommunications operator.
HR
Apps for HR departments are more complicated as HR processes cover different stages of the employer-employee relationship. In this example, we will focus on the recruitment process and the training process.
Candidates for user stories splitting:
- Working with notes from the admission process.
- Print of the profile.
- Emailing the profile to other colleagues.
- Archiving notes and the profile.
- Looking for the training.
- Invitation to the training.
- Sharing training details.
Example of split by operations in HR application.
Can you think of anything else?
Do not hesitate to write it down into your backlog and try to see for yourself that everything big consists of small things. It will help you finish smaller things sooner, with fewer errors, and especially with faster feedback and user verification.
