How to Split a Big User Story in Jira (By Rule and By Workflow Step)
A story that is too big for one sprint needs splitting. Split it by business rule or by workflow step into smaller stories that still give the shopper something, shown on a real Jira backlog.
Step by step
Too big
- Split a story. A story that is too big for one sprint won't get finished in that sprint, so you split it. Each new story must still give the shopper something on its own. Here are 2 ways to do it on a Jira backlog.
- Split by rule. The story Cancel an order before it ships is estimated at 5 story points. Open it from the backlog. Its Acceptance criteria hold 2 different rules: cancel the order while it is not packed yet, and hide the cancel button once it has shipped. That means one new story per rule. At the bottom of the backlog, click Create to add a new item. Click the type picker for the new item and choose Story, so each piece is tracked as a story and not a task. Type the first rule as the summary, Cancel an order that is not packed yet, and press Enter. Jira adds it to the backlog. Then type the second rule, Hide the cancel button once shipped, and press Enter again.
By workflow step
- Split by step. The next big story, Track a parcel on a map, is an 8. Here the shopper goes through steps in order: first they see where the parcel was last scanned, then they see it on a map. So the first step becomes its own story. Type See where my parcel was last scanned and press Enter. The map comes second, so type Show the last scan on a map and press Enter. Even the first story on its own is useful to a shopper.
After the split
- Four small stories. The backlog now has 4 smaller stories, and each one can be tested on its own. The team can now estimate them and fit them into sprints.
- Not into sub-tasks. Don't split a story into design, build and test. Those are sub-tasks, and none of them helps the shopper on its own. Once the new stories exist, close the old big story so nobody plans it twice.
Recap
- By rule, by step. Split by rule when the acceptance criteria hold different rules. Split by workflow step when the shopper goes through stages. Either way, every new story must still give the shopper something.
Common mistakes
- Splitting into design, build and test. Those are sub-tasks of one story, and none of them gives the user anything alone. Split by rule or by workflow step, so each new story can be shown and tested by itself.
- Leaving the old big story open. If the original stays in the backlog, someone may estimate and plan it again next to the new stories. Close it once the new stories exist, and add a comment saying which stories replaced it.
- Copying the old estimate onto every new story. A 5 doesn't become two stories of 5, or two of 2.5. Have the team estimate each new story from scratch, because one rule is often much bigger than the other.
- A first step that is useless on its own. When you split by step, the first story must still work alone, like seeing where the parcel was last scanned before there is any map. If a piece only makes sense once the next one is built, split it another way.
When a business analyst uses this
In a backlog refinement workshop, a story like Cancel an order before it ships comes back too big for one sprint. The BA reads its acceptance criteria, makes one story per rule, moves the matching criteria onto each new story and closes the original, so the team can estimate the new stories in the same session.
Questions people ask
What is the difference between splitting a story and creating sub-tasks in Jira?
Splitting makes new stories, and each one gives the user something and can be tested alone. Sub-tasks break one story into pieces of work, like design, build and test, that sit under that story and give no value on their own.
When should you split a user story?
Split it when the team doesn't think it can be finished in one sprint. A high story point estimate is a common sign, but what counts as too big depends on the team.
What should you do with the original story after splitting it?
Close it so nobody plans it twice. How you close it depends on your project's workflow, so use whichever closing status your project has.
