Business-as-usual (BAU) work such as upgrades, updates and maintenance does not qualify as R&D. Bug fixes usually do not qualify either (see below). If a team's backlog is mostly this kind of work, it will have little R&D to report, even if the work is hard.
Before you create a chore PBI, pause and ask: could this be done in a new way that hasn't been done before? If so, the way you do it can become the experiment.
Don't create an epic to complete the chore. Instead, create one to investigate a new, untested way of completing it.
Epic: Upgrade an Angular app from version 10 to 20.
❌ Figure: Bad example - Routine upgrade work, which doesn't qualify as R&D
Epic: Establish whether an AI-powered technology uplift program can upgrade an Angular app from version 10 to 20.
Success benchmark: Define it before you start, for example the app builds and its tests pass with no manual code changes.
✅ Figure: Good example - Investigates a new way of doing the upgrade, with a way to judge the result
The upgrade still happens. The difference is that the team is now running an experiment on how to do it, and recording what it learns. See Do you make your R&D experiment outcomes measurable?.
Reframing only works when the new approach is genuinely uncertain. Don't relabel routine work to make it look like R&D.
Bugs are a grey area, so check with whoever prepares the report before counting them.