[Select Repost] Splitting User Stories
Having trouble splitting user stories? This post , written by Faisal Ansari, gives a framework for knowing whether your user stories have the information and detail your team needs to develop a valuable product.
A common challenge faced by inexperienced Scrum teams is related to splitting user Stories (in Scrum, Product Backlog Items or PBIs) so that they are granular enough for development. The INVEST model is a good way to test whether user stories are well-written.
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
Independent – Each user story must be independent of each other. This prevents any overlap between the items; moreover, it allows the team to implement them in any order.
Negotiable – The details of the work must be negotiable, both among the stakeholders and the team. Specific requirements and design decisions will be fleshed out during development. Many agile practitioners recommended writing user stories on a note card — this is intentional so that a limited amount of detail can be prescribed.
Valuable – Each user story must add business value to the product, the customer and/or the users’ experience.
Estimable ¬– A good user story can be understood well-enough by the team that they can estimate it — not accurately — but at a high-level they perceive that it has size. It is helpful to understand the relative effort as compared to other user stories.
Small – A user story is not small if the team cannot get it done within a single Sprint. As large user stories are split into smaller items, greater clarity about the size and implementation is achieved, which improves the likelihood that the team will get it done within a Sprint.
Testable – Each user story should be testable; this is a common characteristic of well written requirements. If the team cannot determine how the user story may be tested, it is an indication that either desired functionality or the desired business value is not clear enough.
Vertical vs Horizontal Splitting
There are two common ways to split user stories: vertically or horizontally. Horizontal breakdown of user stories splits the item at an architectural component level. Example: front end UI, databases or backend services. Whereas, a vertical slice results in working, demonstrable, software which adds business value. Therefore, it is recommended to slice user stories vertically so as to reduce dependencies and improve the team’s ability to deliver a potentially shippable product increment each sprint.
Splitting User Stories Example
As a customer I can pay for my order so that I receive the products
If the above user story was to be split in a vertical manner, it might be broken down into the various ways a customer can complete a payment. As follows…
As a customer I can make a credit card payment for my order so that I collect reward points on my credit card.
And/or
As a customer I can make a PayPal payment for my order so that I can securely complete my purchase without sharing credit card details with another retailer.
The key point to note in the vertically sliced user stories above is that each story passes the INVEST tests mentioned earlier and therefore a Product Owner can prioritize these user stories based on customer needs. However, if a horizontal approach was used to split the user story (i.e. split by architectural layers and components) then the implementation of such requirements would result in working functionality only when all horizontal components are eventually integrated.
Breaking down by Workflow
Another approach that is commonly used to breakdown user stories is focused on the individual steps a user may take in order to achieve their end goal — that is, a user story which describes a long narrative or “user flow” through a system may be sliced into steps which represent portions of the user’s flow. Continuing from the example above of a customer making a purchase online, the user story can be broken down into the following:
As a customer I can review the items being purchased for my order so that I can be confident I’m paying for the correct items.
As a customer I can provide my banking information for my order so that I can receive the products I ordered.
As a customer I can receive a confirmation ID for my purchase so that I can keep track and keep a record of my purchase.
Other Methods
There are many other methods that can be utilized to breakdown larger user stories such as:
- Breaking down by business rules
- Breaking down by happy / unhappy flow
- Breaking down by input options / platform
- Breaking down by data types or parameters
- Breaking down by operations (CRUD)
- Breaking down by test scenarios / test case
- Breaking down by roles
- Breaking down by ‘optimize now’ vs ‘optimize later’
- Breaking down by browser compatibility