Story Slicing and Story Splitting- When and Where to use

When a Product Backlog Item is deemed too large by the Developers to be completed in a single Sprint, work should be done to refine it into segments that can be completed during a single Sprint.

Story Slicing and Story Splitting- When and Where to use

As late as possible, and only where an experiment is too big to validate in one Sprint.

Scrum is not a reductionist process. It is about innovation, and learning to build the right thing at the right time.

Splitting usually happens while refining the Product Backlog or in Sprint Planning to make Product Backlog items (PBIs) 'ready'. It is taking a larger PBI and breaking it down into smaller pieces of potential value. And so on and so on.

Slicing happens when the Product Owner wants to understand various options for implementing a larger PBI (aka Epic) to get quick feedback and manage risk. Work that might not be valuable isn't considered. This too may happen while refining the Product Backlog.

Unlike splitting, not all the parts of the Epic may be needed when slicing.

Really depends on the situation. But the main thing that should be adhered to as mentioned before is that the developers should be confident to be able to finish a story inside the timebox of their sprint. 



This means different things for different teams. When the story is to big, the team should focus on how they can size it down, so it can be done within one sprint and it delivers a valuable increment when the story is complete. 



So don't split tickets into a Part 1/2/3 but focus on which values does this ticket deliver and what can be done within a sprint to deliver some of the value. 

Additionally to what was written above, its a good idea to avoid doing this yourself, if you are SM or PO. Try your best to make sure developers learn and participate in refining Product backlog and proper preparation of PBI' to be "ready". which may include many different techniques, not only slicing and splitting.