[ls6]

While I appreciate the insight I cannot fully agree with your conlusions. I've been a PO for the last 16 months (not my first scrum project) in a research project where it is simply impossible to have a long backlog. I bearly manage to keep one iteration ahead of the team. But it works. I think it does because I'm the person actively driving the development, I know the direction we should go and I do want the results

And that latter part is where, in my opinion, lies the difference. Not in the artifact but in the person.

[hansef]

In my opinion, anything on a product backlog which exceeds a 2-3 iteration horizon should be spun into a product roadmap document instead - as a general rule of thumb, if you don't have enough information about a story to sit down and write a clear set of acceptance criteria for it right now, it probably doesn't belong in your product backlog.

2-3 iterations is doable - trying to maintain a backlog of stories 2-3 releases ahead usually results in a big sloppy mess of a backlog.

Unfortunately, I've worked with many clients where thinking about priorities in the future far enough to have 2-3 days worth of stories in place beyond the current iteration is a struggle. This is where things usually go really off the tracks, because you build the thing it's easiest to describe right now to keep everyone working, or run from externally-directed fire to fire, instead of setting a cadence of development which represents the business' true near-term priority mix.

[ls6]

On big backlog: you have surprised me here. My backlog has all kinds of stuff in it that I'm not even sure we will ever build (as I said before it is a research project). As long these vague stories are more than 2 iterations away they don't distract the team but, at the same time, show them roughly what I am considering in the long term. I personally find it very important that the team knows the big picture and where and why we are heading so they can take more informed decisions. As a bonus once in a while I get unexpected insights from the team. They are smart guys, after all :)

Regarding the client involvement, what you describe is, in my eyes, not your problem but your clients' - they clearly have no idea what they want to have. If the project is important for the client I sometimes add one more (senior) person to the project from our side and charge him with the task of helping the client to figure out their needs. This new person takes over the PO role on the team side but spends most of his time with the client asking questions, guiding him etc.