How do you break down user stories when they are too big?

Acquiring proficiency in breaking down user stories into smaller, more manageable tasks is a process that evolves with practice. Teams will refine their ability to segment stories efficiently through accumulated experience. Engaging in thorough discussions around aspects like dependencies, acceptance criteria, task descriptions, and the anticipated workload can swiftly identify oversized stories in need of division. The essence lies in fostering transparent communication and leveraging past experiences as a guide for continuous improvement.

It's important to understand, and many teams struggle with this, that splitting user stories into smaller user stories, is still about getting user feedback, not tasking out tech components and individual tasks. User tasks can be split from big user stories. For example, a user story to create "contribute to a LI Collaborative article" can be split into: Enter a comment, View characters used against character limit, cancel my comment, add my comment. Some might say this can all be one user story and these splits are part of the acceptance criteria. Both are correct. Too big (need to split) is a relative judgment of the team as they discuss and estimate if they can get the work done.

A invaluable aid in ensuring user stories are indeed delivering profound value that can be effectively communicated is to group every user story under an Epic. The epic summarizes the high level objective, the business value it will deliver to customers and the constituent user stories that will achieve the stated objective. In this way, the 'child' user stories are juxtaposed against one another to ensure they form a complete and compelling case for contributing real value to the overarching objective. If a user story doesn't belong or is too ambitious, it will stick out like a sore thumb.

Grouping user stories under large epics is a powerful mechanism for vetting the suitability of those user stories. Epics describe the overall objective, the targeted business value, and the user stories required to achieve that objective. Note that epics do not necessarily have to target functional requirements, but can include non-functional objectives such as improving performance or interoperability. The user stories under a given epic should state easily understood, measurable and achievable requirements that collectively tell a compelling story of accomplishing the epic goal. As such, each story must 'look like it belongs.' If a user story is much larger than its siblings but is very important, it should be made into its own epic.

The team finds their way in judging what is too big with experience as they work together and collaborate. They must discuss the user story and various approaches to the work, design, and details in order to gage if it is too big.

I would caution spltting by what is mentioned here "the different types or sources of data involved, the different screens or components of the user interface". Stick to splitting by user workflow or scenario vs. tech component. Data sources can work but if it's about the user goal with that data source more than the technicalities of the data source itself, still needs that focus on user value. Data source for example is a good way to test out the user value with one data source before building out all the others.

Your article effectively addresses the significance of breaking down user stories into smaller units, a crucial step in Agile methodologies. I'd like to emphasize that the next logical step after this breakdown should involve prioritizing these smaller parts. As not all features are equally essential or frequently used, focusing on high-value components is key for efficient resource allocation. This addition complements your insights, underlining the seamless progression from breaking down stories to ensuring that development efforts align with customer needs and deliver maximum value.

There is vertical and horizontal slice. Ideally you want it vertical, where your story after slicing still have all layers (UI, Functionality, database...) because only that way you will able to get complete felling and get appropriate feedback on your feature. Horizontal slice will mean that you are waterfalling the process by doing step by step items which are part of same feature but sometimes can be unvoidable. Also you want it Lean. In first versions stories should contain only must have features so your slicing technic should consider this. Later on it can change. Easy way to see if story needs slicing is if it has conjunctions and connectors (like "and", "or") in its description or too many Acceptance Criteria's ...

Breaking down complex problems into manageable units is a cornerstone of strategy development. This principle aligns seamlessly with Agile's approach to breaking down user stories. Just as strategy tasks are divided into achievable steps, Agile breaks user stories into smaller tasks for incremental value delivery. Both strategies enhance efficiency, mitigate risks, and maintain alignment with overarching goals. It showcases the shared principle of focused, adaptable development in both contexts.