On the opposite end of being too technical is being too vague. Even though "story," is in the name, this isn't a writer's workshop. You're not trying to explain how this software will help the user avenge their Uncle Ben; you just want to cover the absolute basics. It should be an exercise in minimalism.
Your team needs to know the who of your story, the what of your story, and the why of your story - and that's it! Often, there should only be one of each of these things in every story. How to avoid this mistake?
The easiest way to tell if your story is too long is if you get bored before you finish reading it. A more strategic approach, though, is that if you find yourself with a long user story, start breaking it down.
Rather than throwing pieces of it away (unless they're truly pointless) split the story into several stories. This will make the intentions more clear to your team as well as make each story more manageable during development.
One of the most effective ways of making sure you're hitting the right level of detail (and planning them in the right order) is to do user story mapping, which is a technique devised by Jeff Patton
. Using this technique, you map out the end-to-end experience of a user and how they interact with your product along the way. This helps you think of features as tasks that the user completes. This post
details everything you need to know about effective user story mapping.