How do you split large or complex backlog items into smaller and more manageable ones? (2024)

To expend on the INVEST Criteria, make sure that your item, and item once split is "feedback able" and demoable, not a piece of value dependent on other items or other teams work. Your backlog item to split and the splits need to be something end users can see, touch, play with and give feedback on, they need to be an "increment of value", not a piece dependent on other items to show value.This will help ensure you get relevant feedback and deliver in increments faster to your users!

The most effective method of story splitting will vary from team to team and project to project. Therefore, trying out several approaches is crucial until you find what works best. The Three C's Technique INVEST Criteria Epics and Themes Use Cases and Scenarios Prioritization Techniques

It's common to decompose large items only on the scope dimension. It's assumed that the final design is clear and can be just broken down into smaller items.Very often, we may have a clear understanding of the JTBD but a very vague understanding of the final design that will make the customers happy.This is a common mistake when some design is forcefully pushed as final, and the uncertainty is masked as extra effort. Effort-based contingency is the wrong tool to address product uncertainty.The right tool is iterating, and learning, and the decomposition should look NOT like "multiple precise details that will perfectly fit together in the end" but "multiple small experiments that will tell us what the end result should look like".

The most common ways to split a backlog item:1) Basic to complex - What is the most basic flow/step/way of a user using this? Then in other splits, add on more complexity, bells, and whistles. Incrementally providing more value in each item.2) User Scenarios - Each user scenario can be a separate item, the most common user scenario first perhaps, then alternate paths. For some items this is very similar to the basic to complex approach.There are many other patterns and ways to think about splitting, all depend on value in each split, and incrementally building value in. Splitting effectively can help teams, learn faster, and release faster, as well as prioritizing better to leave unneeded pieces out.

User interface elements in your design, like forms, make it easy to decompose large backlog items. If a backlog item requires many of interface options, break down the feature by form elements. For example, if a form has a drop down for credit card type, decompose the backlog item into one for each credit card type or one for a single specific credit card type and one for the remainder of the types.

You can also use this as an opportunity to learn iteratively. If the feature is slightly complex and stake holders are not sure of exactly how they want the feature to behave, break it into chunks and deploy it so they can get their hands on it. (Depending on the risks of the feature, of course)

We had a large story that had a lot of "And"'s that kept growing during the sprint. It had multiple stakeholders and systems involved and they had not decided on all the logic behind the feature. We determined to stop work, break it into a bunch of smaller stories, and start on the ones that would at least provide some value while they figured out all the rest. This will possibly give them a chance to learn about this feature and how it will actually be used to achieve their desired outcome.

A discussion on story splitting is not complete without reference to the story splitting flowchart here, my go-to... https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/#flowchart.

Don’t forget that when the team is struggling with decomposing a large work item, more research might be needed. Try creating small “spikes” to answer key questions.