Breaking down an epic that includes a lot of tech work - where do you draw the line?
When I started Scrum I was a major proponent of the INVEST principle, especially when it came to Estimable, Small and Testable. Not that the others weren't important, but I strived in breaking down stories to be as small as possible, and with that they naturally became easy to estimate and easy to test. When I knew that an epic would require significant technical background work to support the user facing feature, I would generally make that its own story. I know that violates Independent (which is hard enough to do), and one could argue Valuable as well since it's not directly valuable to end users, but I felt that splitting up the tech background work and user facing work made things more manageable.
An example of this would be retrieving and showing data to the user from an API that doesn't exist yet. I know based on past stories that creating the API is roughly 3 points using the modified Fibonacci sequence and showing the information on the screen is 2 or 3, depending on how the UI will look. And there may be other stories depending on business needs, but that gives you an idea. The API itself meets the E, S and T since QA can test it with Postman, and as I mentioned above it could be argued that is meets V indirectly.
Where do others draw the line between writing a story that only has tech work and a story where the tech work is expected to be included? Do you wait for Discovery or Estimation where you're told it's too large and needs to be broken up?
Where do others draw the line between writing a story that only has tech work
Why pretend that's a story at all? It might be a different kind of Product Backlog item.
What matters, in Scrum, is that something of value is delivered every Sprint, even if most of the work has been technically facing. A wise team might implement a small "tracer bullet" user story whiich allows architecture and infrastructure to be validated, for example.