On the other hand, it's critical to remember that stories are (I think Mike Cohn said this) "a reminder to have a conversation". I've found that people new to agile constantly struggle with its intrinsic ambiguities and its reliance on a bit of chaos and emergence to sort itself out. In our project, we're handling this by keeping stories in current and at the top of the backlog in a very testable, verifiable that it is doneness state. They are typically 1 or 2 points on the 8 point scale, sometimes 3. A lot of the big system stories that are just big because of the heavy lifting they require behind the scenes are done (eg set-up the amazon s3 encrypted url generator or other things with low BV but high effort). As you go down the backlog, you see more and more dandelions - stale stories, too big stories, non-testable stories, etc. These are the reminder stories. In fact it seems like dandelions are a reminder to the scrum master and the product owner to do more work!
Something I've struggled with in the lack of hard and fast rules department is, when does a story have to deliver business value (BV) and when does it not? Is it ever ok to have "system" stories (hahaha, The system shall do everything I want in 3 weeks for $10)? I want philosophically for every story to deliver end-user BV, but in order to get there, we were ending up with 8 point stories that were just not helping the developers get stuff done. We argued about it, and we decided that there are some cases where the benefits of a non-BV story out weigh the potential drawbacks of "rewarding" the team with burn down for a story that is really a dependency for other stories to deliver BV. Setting up amazon cloudfront and s3 to use non-shareable urls for digital assets was a piece of architecture work that took a developer 3 days to do that then unblocked a large number of BV-delivering stories. We elected to point and burn down these stories, and I think the morale boost this generated was worth it. Sometimes the psychological needs of the team outweigh the benefit of philosophical purity, which can be intellectually interesting but not always pragmatic.
In conclusion, making agile work is all about being pragmatic most of the time, and reaching for the higher principals when it's a win. And it's a lot of freakin work. Keeping your backlog of stories accurately prioritized and testable is a full time job. If you're finding that your adoption of agile isn't working, ask yourself how many hours a day is your scrum master spending managing the backlog with the product owner. In the middle of a project, this could easily be 3 full business days of work a week.