How big are your stories?

The answer to that question is that depends. And it depends on what you are using them for. Stories that are far in the future is written to give people an idea of which stuff will be done "sometimes, but not now". These stories can be very big since if you're not going to build it, you don't know the details. That is self explaining: why would I want to know the details about stuff we're not building? But then you could say that sales people need details to be able to know which customers to target. But that problem should probably not be addressed by the product backlog, but the business plan. If you've targeted a specific client who have a specific need: simply write down on the product backlog item to take that customer into account when you're specify the details.

When you get closer in time: you break down the story into smaller stories, which can be handled and prioritized. Divide stories after the following principle:
* They can be prioritized independently - that is - they all have their own busines value
* If they are up for building in the near future, never make them larger than 1/3 of a sprint, so you don't risk having to finish a sprint without any completed stories
* Make them possible to build independently. If they are all connected and must be built at the same time, the previous advice is of no use.
* Don't divide the stories yourself: this is what you have story writing sessions for. Because only developers know which things can built independently and only the users know what has its own business value