how do you go about handling stories that take more than one month to reach the DONE-DONE state? Of course one could always split them into several so called "technical stories", but they are, with the exception of refactoring spikes, a big no-no in Agile, aren't they?
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?
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.
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?
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.
Ken had some good advice. We have found that the most important things to keep in mind are that...
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.
Splitting to technical stories or running as mini waterfall are good to try as long as it makes sense to team & relevant stakeholders
