It's a bit unclear if you're asking about estimation or about prioritization.
I think lots of answers here tackle the prioritization aspect, so I won't go into that.
If you're asking how to estimate your efforts, given that much of them end up being unplanned work, then there are a bunch of things you can do, but a complete solution is probably impossible to find, for the simple reason that R&D projects by nature contain a high degree of uncertainty that cannot be easily quantified at the start of a project.
But first let's talk about what you can do.
Where is this unplanned work coming from?
It sometimes can seem like unplanned work is just dumped on your team from above, sideways and every other direction. But sometimes a team can bring it on itself. A trivial example: a team that ships in a big, big hurry and delivers buggy code naturally spends a lot of time putting out fires later. By the way, shipping buggy code isn't a way of saying "hey, you suck at coding" - sometimes it's really due to outside pressure no the team to sacrifice quality for cost.
How can you make unplanned work go away?
If you're looking to reduce the amount of time you spend on unplanned work, first you need to identify what sort of work it is, and then work to reduce it. For example, if your development team constantly gets pulled to assist field engineers in installing and configuring the system in production environments, then maybe you should prioritize automating those deployment tasks; redesigning them to be easier, less risky, etc.
Measuring unplanned work won't do you any good
It might seem like a good idea to measure how much time you've spent on unplanned work during the last few sprints and extrapolate from there, but it's a fool's errand. Predicting the unpredictable is futile. Your next sprint may go completely smoothly, and the one after that might be derailed by the biggest clusterf&ck production problem you've ever encountered. You're just not going to be able to predict that.
The problem is that software development, in almost all cases, contains a good portion of unplanned work. Sometimes you just don't count it as such. It's easy to see a delayed project as just under-estimated, but most of the time the problem isn't with how you're estimating, but with what you're estimating. Unless your development projects are completely repetitive (constantly developing the same product over and over) they'll have a high degree of uncertainty built into them, owing to using new tools, tackling new problems and so on. You start off with a great work-plan, but after two days you realize that the library you were going to use isn't really supported by the target platform, and now you have to find an alternative, or, heaven forbid, develop something on your own. Those are the real kickers - the things you just didn't count at all during planning.
So how do we estimate, given all this unavoidable unplanned work?
The whole idea of doing only what you planned on doing, with minimal unplanned work, is just not in the cards for most R&D teams. Obviously. That's why agile is so popular. You can try to minimize unplanned work, to some degree, but in the end your projects' schedules are always going to be dominated by the unplanned stuff. Once you realize that unplanned work is your bread and butter, you can now adapt your project management methods to handle it better:
- Drill down and plan your iterations in detail. It doesn't take a lot of time, if you have a decent PM tool. Break things down to hour-sized tasks, where applicable. This will flush out a lot of the "unplanned" stuff.
- Prioritize the risky stuff. When you break things down to small pieces, you immediately see where your uncertainty lies. It's in those tasks that you don't really know how to break down further, and that you're not really sure about how long they'll take at all. Start from those, if possible. This way your estimate will still be off, but it'll stabilize significantly as your iteration progresses. You won't find yourself at the last couple of days of the iteration suddenly realizing you need 10 more days to finish what you started.
- Negotiate with the project/product managers to work on the most common external source of unplanned work. e.g. would better documentation save your engineers a lot time explaining stuff to field engineers or customers? Then demand to allocate time for this as part of the development effort.