The examples were created in the form of a user story map using the ScrumDesk app, where you can easily create a backlog from epics to embedded features to user stories.
So far, in our consultation with the agile teams, we have always encountered unfamiliarity in each team about how to split the requirements into smaller ones in the right way. This usually ends with comments saying that it is not possible to divide the request into smaller parts.
We can’t do it, it makes no sense, it is not possible, but with us it’s different, but you don’t understand.
We constantly listen to that. So we decided to show you how you can do it.
User stories splitting by business workflow
Many products, services, or applications allow clients to process data from their complicated internal, or commercial processes. And the processes steps can be an excellent way of dividing requirements.
Besides, if you focus on the process from start to finish:
- this allows you to create a working app very quickly,
- it supports basic workflow,
- quickly build an underlying, yet correct architecture that can be continuously improved,
- you get user feedback very quickly because they don’t have to imagine how this will result,
- the product can be used soon.
Does the result have to be deliverable to the production environment?
For small apps, the result may be the first version, the first minimum marketable product. However, in the case of more complex products, it is not recommended to consider a split of requirements as unnecessary. Get out of your comfort zone.
Smaller requirements make it possible to build the product continuously, gradually, and can even be used as a minimum viable product. And only when a sufficient amount of functionality is done, only then it is ready to be published in the production environment. And that is why the split of products into epics or even smaller user stories certainly has practical significance.
Perhaps the simplest example that helps you understand is Netflix. At the same time, it is an example of a more general-purpose functionality in which the data changes but the process itself remains the same.
The steps of the process are transparent to probably everyone. I choose a movie from the selection, watch the movie, and rate it. Well okay, before that I have to log in.
By the way, do you also have a similar experience with Netflix? In this case, the minimum product might only be searching on Netflix :).
eCommerce apps are the best example for explaining the division by process steps. Each of us has already bought something in a similar system.
- The buyer first browses the products in the product catalogue.
- They put the products they like into the basket or favourite list.
- If they decide to buy the items, they pay for them.
- Finally, there are no steps left other than monitoring the delivery status.
Now imagine that your app has these steps functional. In principle, the client can buy the product directly, or at least simulate their purchase.
Of course, any epic can be implemented in multiple ways. This will help identify the minimal product. E.g., in the first version, you will only support payment to the account, or only product selection from the list without the option to search. Or only through the search.
Another example is the app for electronic banking. These apps are now more complex than ever as they support not only typical clients but also insurance products, investments, pension funds, etc.
In our example, we are going to take a look at bank retail, that is, the departments of the bank taking care of us, their typical clients. Our life is quite simple in this case. We look through our accounts. We then need to pay receipts, invoices. And then we can look through review reports, etc.
We will look at payments:
- First, we choose or add a payee.
- We then enter payment details.
- Once we enter it, it’s usually a good idea to allow users to check the payment before the payment.
- Finally, enable the user to download the payment receipt, if necessary.
In the case of an insurance app, we can easily see an example of two processes:
- The overall process from the selection of the type of insurance to its payment in case of damage.
- Claims processing process.
In the event of a claim, the victim contacts the insurance company and reports the event. To process this event, the employee of given insurance is assigned to the case. The employee then approaches the injured client and evaluates the level of eligibility of insurance payments and the level of damage. Then they decide on the outcome of the processing of the claim and closes the case.
After this processing, the next step of the main process starts, and that is refunding.
Telecommunications operator – self-care app
If you are a product owner at a telecommunication company, it can be your responsibility to take care of the customers. I.e., the app for customer self-service.
After the initial login, the user will usually get to the screen with an overview of their current products. Subsequently, they can view the details of their products or purchase, activate new products and services. Alternatively, they pay for the delivered services and products. And as the last step, there is the possibility of possible client support.
Such a division is not just a matter of IT. Imagine that you want to visualize HR processes in which you have an overview as an HR manager. Or, as a Product Owner, you have to create an IT system that supports HR. In both cases, we can use the division into smaller parts with respect to HR processes.
In this example, we look at the employee-centred process:
- HR employee will start hiring new employees.
- After that, the selection of potential candidates will begin.
- When the employee identifies them, they need to conclude an employment contract, inform the insurance company, ensure that new accounts for the internal IT system are created, etc.
- The employee then must be trained.
- When the employee starts working successfully, they need to continue to be supported either in his personal development or by promotion.
- And finally, the end comes. The employee quits the job.
Again, you may think that different alternatives can do each step. And we’ll go through that later when we talk about other ways of dividing.
Can you think of anything else?
Do not hesitate to write it down in your backlog and try to see that everything big consists of small things. And that you’ll finish the smaller tasks sooner, with fewer errors, and especially with faster feedback and user verification.