When agile coaches arrive in a new mission where the goal is to transform teams into Agile or even Scrum, there is often a first essential topic to deal with them: how to split his user-stories?
This article will propose different ways to split in small pieces the product backlog in order to purpose manageable user-stories by the development teams within a sprint.
Version française: Comment découper ses user-story ?
But why split our user-stories?
There are several reasons that justify the splitting of user-stories:
- A user-story must be fully achievable in a Sprint
- Have a better transparency on the project
- Have better feedback and more regular
- Have a better learning
- Have a faster value delivery
Indeed, the user-story splitting really brings a lot to the Agile organization.
However, the splitting is not so simple and there are different methods to do it.
Start with the MMF concept
I like to use the MMF (Minimum Marketable Feature) to start my splitting. When you have a functionality, what is essential and what is optional?
For example in one form:
We have a main user-story :
“As customer, I want to contact the customer service so that I find help”
This user-story is a mandatory for the website; the customer service is essential for all customers. So, this user-story is an MMF.
But, we can have a best rendering if we add somethings ; for example, this user-story :
“As a customer, I want that the city is in auto-complete when I fill my zip”
This user-story is user-friendly but not necessary to have this form. So, it’s not an MMF user-story.
These two user-stories could deliver separately because we have one MMF user-story and one not MMF user-story. The first will deliver at the first release of the project (or first part of development) and the second later.
So these two user-stories will be independant when we will deliver them.
I advice you to use this practice to split your user-stories. This practice consists of splitting user-stories without worrying about architectural aspects. User-stories can potentially intervene on different layers of architecture that are not managed by the same skills (C #, PHP, React / Node …).
This approach becomes more complex when we have a user-story that will concern two different teams; so some teams use the horizontal splitting in this case.
“As a customer, I want to be able to pay for my cart with Paypal. “
User-stories are independant
Each user-stories have to be independant. For example, we will create one user-story by mean of payment :
“As a customer, I want to be able to pay for my cart with credit card. ”
“As a customer, I want to be able to pay in 3 times. “
And when a user-story need some teams?
This user-story is the result of a vertical splitting can involve several teams in the company: the front team that will integrate the payment method on the site, the payment team that will manage this new payment method in their PSP and the back team who will have to recognize this payment. It is not uncommon that the front, the PSP and the back are all on very different systems.
This type of case arrives and there are choices to be made like refining the splitting; so, it’s an example of splitting:
“As a customer, I want to see the Paypal payment method displayed. » (For the front)
“As a customer, I want to be able to pay for my cart with Paypal. » (For the PSP)
“As order manager, I want to see the orders paid with Paypal. »(For the Back)
We have just done a horizontal splitting but it seems to make each feature independent (although basically if it’s true, the ultimate interest is to have the 3 to actually put this means of payment in production) .
So what is the good practice in these particular cases?
To be honest, it’s very difficult to determine when you do not have the final context.
There may be two different practices. Some will say with conviction about one of the two methods; for my part, I think the context will be the answer to the question.
Vertical splitting and then duplication
When you have concepts like Scrum of Scrum with PO committees, it may be interesting to duplicate the user-story for each team and not split it again.
The global user-story will be validated when the 3 teams have finished their user-story knowing that the 3 teams will try to develop them during the same period.
Vertical and horizontal splitting
When the organization of teams is not optimal, it is better to make a second horizontal splitting; so, we have 3 new user-stories.
On the other hand, it will be essential for the teams to communicate for the delivery of the functionality in its entirety. Although the back team and the PSP team could deliver their user-story before the front team.
Make user-story INVEST
The acronym INVEST is interesting because it defines the criteria of a quality user-story.
- I for Independent: each user-story must be independent of others on the current sprint.
- N for negotiable: the details must be negotiable. That’s why we write a user-story in one small sentence and a simple management rules
- V for valuable: each user-story must bring business value for trades or customers
- E for Estimable: each user-story must be estimable by the development teams; For this, these teams have to understand them well.
- S for Smallable: each user story must be well cut out to be delivered within just one Sprint.
- T for Testable: all user stories must be testable.
By respecting these rules, your user stories will be better qualities and will allow to better organize your sprint.
The splitting of the user-stories is often complex but it is important to do it in the best possible conditions because the result of this splitting will be important for the good progress of the sprint of the teams.
Do not hesitate to be accompanied by Agile coaches to better lead this often very important phase when starting your sprints. The right choices will save you time on your future projects.