Have you come across "Feature Injection" at all? It works very well with Scrum and other Agile methodologies, and helps you to draw out the backlog from your initial project vision.
I wrote an article on it, or you can also read Chris Matts' comic (he invented it).
As a short summary, it helps you:
- Identify a vision
- Identify the goals of various stakeholders that need to be achieved to deliver the vision
- Find user and system capabilities (with business-focused outcomes) which can deliver the goals
- Create features which allow users and the system to have the capabilities
- Split features into stories for fast feedback
...and now you're in Scrum.
As a note, I'm using "capability" where I used to use "theme" or "feature set" because I've found it makes more sense; we're allowing users to achieve some business outcome, or allowing the system to do something valuable (eg: security, performance).
Remember that Scrum should be collaborative, so even though these might read like analysis phases, conversation is more important than documentation.
You may also want to consider estimating the entire release backlog at a capability level, rather than splitting it up in advance. Every team I've seen who breaks the backlog down up-front ends up spending significant time "grooming" it. Dan North's article on the perils of estimation, and his other article on Deliberate Discovery, may help with understanding why.
You can split up high-level backlog items as you get to them, or during the planning meeting. If you do this and re-estimate with stories, it's likely that fractal estimation will cause your scope to go up. That's fine; just use a burn-up instead of a burn-down chart; the scope usually rises at a fairly constant rate, so you can still see if you're going to make the deadline.