I read some books about Scrum, but they seem to only be about product backlog, sprints, user stories, the scrum team, and timeboxing — but nothing about vision, roadmap, estimation, and other important things for a top level management.
How do these things fit into Scrum? Is it part of the Scrum Master role? Can anyone give me a "how do I?"
Scrum doesn't really cover the strategic part of planning. In terms of building a vision and a general roadmap Scrum itself won't help you much. However, at this level planning doesn't really differ from what you know, or should know, from other methods.
So unless you know, in general, what you want to build don't bother with going deep into any method.
Estimation is a whole different thing. Once you you have a vision and a general plan you definitely want to be able to say what you're going to build in what time. Here is an excellent two-part video of Mike Cohn talking about agile estimation:
It should dispel your doubts.
You can also check Mike Cohn's book dedicated completely to this subject (thanks Jesse for the comment).
Ken Schwaber has said that "The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog".
The Product Owner is responsible for the overall product and should lead the creation of the vision. This should happen through close collaboration with the team. Conversations with stakeholders that have appropriate experience in business analysis and marketing is helpful.
The vision, of course, should also involve the customer.
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:
...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.
