It's best to break up user stories into small vertical slices and implement them within a single sprint so that you can get early feedback from the customer. That's a great way to uncover misunderstandings about requirements, even though it might seem less efficient. Optimize for rapid value delivery; a little wasted time is acceptable.

That or having to estimate work based on your sprint. This is a 130 pointed task? Oh we only go up to 8.

Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?

Laying the foundations. Doesn't look like a house even after you've done it.

Exactly. You need the end-to-end backbone working so that you can start adding end-to-end user-visible behaviors on it, a few at a time.

Research? Experimentation? Foundations?

Pffft. We're talking crud apps here. Has any innovative software ever been developed in "sprints" using "user stories" and "story points" with a "product owner" and a "scrum master"? I doubt it.

Yeah, I've been on a couple of those. It was XP, technically, not scrum, but we did sprints and user stories and story points, and we had a product owner, and we had a guy who was de facto the keeper of the methodology. It worked really well, too.

And no, it wasn't just crud apps. It was a distributed security auditing tool. Yes, it had a database component, but it was much more than that.