My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.
I have not worked in a scrum environment in a couple of years, but when we did it those items were not included in the story. They were part of a definition of done that the team did not really talk about publicly.
Refactoring stories were also rare, it was just sort implicit in the task, unspoken as part of doing it.
I'd imagine that is why they did not get cut.
But yes, management picked feature priorities, but left the implementation up to the team. So at any given time were were working on the "most important" thing from a business perspective.
The most successful (but still crappy) solution to this that I have seen is developers undertaking guerilla tech debt work. This can be done by bundling maintenance work into an existing task where the two are actually not that related or by simply carving out bits of time between official tasks.
While it "works" it is certainly not ideal that people have to go off the reservation to ensure that the project doesn't implode in the future due to the accumulation of buggy code, performance problems and likely security vulnerabilities.
> proper testing and documentation is the first thing that management wants taken out of the story
That's not breaking down a story into smaller stories though, that's simply not doing some of the tasks necessary for a story to be complete. "Story" is not a synonym for "task"; a story is user-centric not about internals. "Write the documentation for this feature" is not a story and "write the tests for this feature" is not a story, they should be part of your definition of "done".
You're not doing Scrum then. One of the few meetings that Scrum dictates is "backlog refinement" where the dev team works with the PO to get the stories into a workable state.
If you can't touch the stories, you can ask whoever does to break it down. If they don't then you shouldn't ever pick it up into your sprint. If they insist and it doesn't work out then you should call out the incident in your retrospective and hopefully get everyone to agree to do things differently in the future.
Sadly, it’s more like the dev team points out that we really cannot work with these stories then management telling us to deal with it while the BA’s suck their teeth.
There is something odd with this, if you did the estimation. Shouldn't the story points/sizing/estimates preclude this?
Doesn't the team pick the items for the sprint that they think they can complete?