I think that I have some misunderstandings from scrum.
Estimates of some tasks are not measurable. For example researching about something or talking about company road map and etc. I can't estimate how many story points needed to complete these tasks.
Should I define backlog items for this kind of jobs and put them into a sprint? Then how can I estimate them?
Or I have to do them outside of scrum process? For example between 2 sprints.
You specifically mentioned two things, so I'm going to focus on those in this answer. However, you can probably generalize for a wide variety of work.
For tasks such as researching or learning something, many people use a spike (see 1, 2, 3). It's not part of Scrum, but it's a good fit. You should be able to estimate this type of work somehow, although it may be hard without prior experiences. In the end, it's no different than any other story, except that the completion of a spike yields an increase in knowledge and maybe some kind of deliverable that isn't a shippable software product. You place it on the backlog appropriately and do it before you need to deliver the functionality using whatever information you learned during the spike.
If you're estimating in story points, estimating a spike should be fairly easy. It's typically easier to learn a new library than a new framework, a new framework than a new programming language, a new language than a new paradigm. If you have domain experience already, it is likely going to be easier than if you don't have domain experience. If you have to learn multiple new things, it's going to be harder. You should be able to scale up the points for a spike appropriately. It's easier if you're using a Fibonacci sequence or t-shirt sizing for estimation, as opposed to hours.
There are also some other tasks that you mention, like discussing roadmaps and other meetings. These items should live outside of Scrum. They will influence your project planning and development activities, though, and do need to be considered.
First, anything outside the project will reduce the capacity of your team, so you will have a lower velocity that you must consider when planning. If you know that the team will have more outside activities (meetings, vacations) in one sprint than a previous sprint, you can plan for a reduced velocity up-front by planning a smaller deliverable.
Second, if your company roadmap includes things like new technology development, technology acquisition, or any kind of transformation, you may want to plan spikes as appropriate to see how various projects can support this roadmap. You may also need to account for people supporting activities on the company roadmap, both technical and non-technical, which will take them away from projects and reduce project velocity. Of course, depending on your funding structure, you may need customer buy-in and support to add stories and tasks related to internal changes to project plans, which you may or may not get.
From the Scrum Guide:
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
However, a typical Scrum backlog comprises the following different types of items:
You can find more information about what this means in practice here.
"Research something", if related to, for example, software architecture or a framework you want to use, will fall in the category Knowledge acquisition. Therefore, it should appear in the backlog with its estimation.
You will hear some people using the term Spike. Spikes are an invention of Extreme Programming (XP): to learn more about it, look here.
On the other side, "talking about company road map" is an activity that does not belong to the backlog.
In general, meetings, time spent reading emails, etc. don't appear in the backlog, but are taken into account when estimating velocity. I think that this previous question can help you to understand this concept and which activities will influence your team velocity.
