My team is working with the Scrum framework. We have done a draft product backlog with enough detail for the first sprints.
However the upper management wants a development roadmap. How does this need enters into the way Scrum does things? I am assuming the objectives are developed iteratively and not from the start.
There is a difference between the kinds of low level objectives that you iteratively create as a dev team and the kinds of higher level objectives that management cares about.
No matter how agile you work, in pretty much all cases there is going to be a predetermined upper limit on budget/time and lower limit on scope/requirements which management signed off on. What they need to know is whether the project is reasonably expected to stay within those limits, regardless of how you've chosen to subdivide this into smaller sprints and tasks.
A roadmap could be as simple as listing the order of operations and what to expect, e.g. that you are first going to build the backend (invisibly to the end user) before you start on the frontend; or whether you're going to develop individual features (both back and front), or ...
Doing scrum doesn't mean you don't know what you'll be doing, it just means that you work out the finer details of a given task closer to the concrete date of execution of said task; and that you iteratively take a moment to observe the situation and redirect where/when necessary.
High level, you should have an idea of what you'll be doing and the order you'll be doing it in; even if you can't provide a pinpoint date of delivery.
It is a common misconception that scrum, or agile in general, means "don't think beyond the next two sprints".
You should still have a longer term roadmap with high level items in it - but you don't plan those items in great detail and you are prepared to iterate on the plan given feedback, either from users or from the development team. If you're not able to have that longer term view of what you're trying to build, your product is almost certainly going to fail.
Your Product Backlog is a roadmap.
The Product Backlog is "an emergent, ordered list of what is needed to improve the product" and "the single source of work undertaken by the Scrum Team". The work at the top of the Product Backlog tends to be more well-refined. Refinement decomposes and creates new Product Backlog Items so that the work is precise enough for the team to plan and execute on, and the act of refinement regularly adds details, additional descriptions of the work, ordering, and other attributes that the team feels necessary.
The top of the backlog represents the next most likely work that the Scrum Team will be taking on in upcoming Sprints. Although the Product Owner could change that order at any point in time, based on feedback and discussions at the Sprint Review or by conversations with stakeholders that may happen at any time.
In addition to the Product Backlog Items, the Product Backlog also contains the Product Goal, which defines the current long-term (multi-Sprint) objective that the Scrum Team is currently working on.
This view is consistent with a "now-next-later" roadmap. Depending on how much time is "now" includes the Sprint Backlog for the current Sprint along with the Product Goal and perhaps some of the well-refined top of the Product Backlog that would be likely for selection in the next Sprint or two, "next" includes the work that is refined or partially-refined but may still be a couple of Sprints away, and "later" is everything else on the Product Backlog that the team has as options but hasn't been refined.
If your stakeholders are looking for a different type of roadmap, you'd have to work with them. Some types of roadmaps, like date-driven roadmaps, do tend to be very misleading in agile environments. They become out-of-date very quickly as the team changes their understanding of the work and the most important or necessary work changes.
My team is working with the Scrum framework.
This is a red flag. Your team shouldn't be using Scrum. The whole company should. That includes upper management.
If only your team uses Scrum, you are setting yourself up for failure. Scrum requires buy-in from the whole company, especially from upper management.
As mentioned in other answers, your Backlog is the Roadmap and the Product Goal is part of the Backlog. Scrum guarantees that you are working on whatever is most valuable according to the Backlog. Upper management can change what "most valuable" means by working with the Product Owner to change the Priorities in the Backlog.
