How to handle user stories that cannot be split and do not fit even a 30 days long sprint?

Splitting to technical stories or running as mini waterfall are good to try as long as it makes sense to team & relevant stakeholders

Clinging to user stories as the smallest planning unit is one of the abhorrent errors held by agilists.

What's the user story for a bridge? Where is the construction of piers, spans, beams, etc. that make up the substructure taken into account? The construction of the deck (roadway) is of such minor consequence (relatively speaking), in this narrative it isn't even detailed.

How many user stories for a house involve the foundation and the roof? Yet they are the most expensive parts of a building.

User stories are a fundamental tool for scope definition and goal setting for the project but they are not the only tool to use. They help define the purpose for a project and when it is complete. They do not provide the entire scope of the effort involved. They help begin the planning process. They are not the final plan.

Ken had some good advice. We have found that the most important things to keep in mind are that...

1. The code should always be potentially shippable. If there were a huge bug found today that took the entire application down, could you stop, fix the bug, and push to production? It may mean there are some partially completed feature sets, but what everything that is there is high quality, tested, and complete.
2. You must have made demonstrable progress at the end of the sprint. This is important when thinking of how to break the item down. So maybe this piece by iteself does not provide "value" to the customer, but we can demonstrate this piece to the customer and use that to show progress towards the end goal. As Ken suggests, definitely avoid splitting at process lines (develop then test) at all costs. So it helps to think that a story must either provide value, or demonstrate progress towards providing value.

The same way you tackle any epic: break it down into smaller chunks.

There are many different ways to do this. For example, if your project has lots of other (legacy) systems to interact with, try to find a lower-level user story that deals with ONE legacy system. And see how implementation of that impacts the overall epic story.

Another approach is to tackle things from a stakeholder viewpoint.

Check out this post for yet another way to deal with it.

Great answer from Pawel. Some other things to consider:

Done should be from the perspective of who the story is getting delivered to. This is not alway the end-user.

There is a difference between potentially-shippable and shippable. The work that we do we try to be feature complete although it may not be feature-set complete.

All stories can be broken down. It is difficult to do this theoretically during planning.

Try not to break stories down across the process dimension. For example, don't build in one iteration and test in the next. This will impact throughput and can lead to technical debt.

First, do things which do make sense. If it does make sense to split the big story into a few smaller ones, even if you can't deliver those parts to your client separately, why shouldn't you do it? You don't get paid for being perfectly adjusted to what some thought-leaders say.

Second, if the situation is rather an exception treat is like one. If you don't want to split the story into smaller chunks you may push one story among a couple of iterations and agree that this time it will just look like this.

Third, if the situation is rather common think how you can adjust process you follow in a way which actually allows such stories. One thing which comes to my mind is Kanban, where you resign from iterations completely and you can deal with one XXL story and at the same time build a lot of smaller ones as you don't limit work basing on time but you limit a number of concurrent tasks. In this case one huge story would take only one slot but it would use it for a longer time.

Four, don't be orthodox on delivering value to a client. If you wanted, and needed, to do some housekeeping in architecture which brought exactly 0 value to your customers, but helped you to limit maintenance costs would you reject such task? Probably no. And yet you would somehow put it in your backlog.

After all agile is about flexibility, about reacting to changes and not about keep rules at all possible cost, right?

If you genuinely can't split the story into valuable chunks, I'd go with "smallest testable component" to slice it up.

Can you give an example of a story?