We plan 2 week sprints with all tasks and bugs as much as we can. Every once in a while our QA Lead will assign the developers "bugs" mid-sprint for UI inconsistencies or non-emergency (or what he perceives as an emergency that actually isn't).

This is really frustrating to me, as my tasks of late are dealing with a new product about to be released and then I get a "bug" assigned to me about how the QA Lead doesn't like the layout of a registration form on a web app I haven't touched in who knows how long and I need to fix it right now.

I guess that my question is actually this: What is the "official" definition of a bug, what kinds of bugs are appropriate to interrupt planned tasks to fix and what can I push back on?

The whole idea of Agile is that the quality is built in. The developers and testers should be working together as a team to do so. From you question I'm sensing annoyance with the tester, who is just doing their job. What can you do to improve the working relationship?

If you have a product owner, the product owner should be prioritizing the bugs. If that's not an option, you might want to make a rule that in the sprint, new work is completed first, then bugs. If the bug needs to be done before that, it can be specified in the daily sprint.

If you're getting tapped on the shoulder for silly stuff, designate someone who is relatively client-facing to be the 'stakeholder' and tell the QA lead that all 'emergencies' have to go through her approval first.

so looking back at your question - I'm getting the sense that both you and the QA lead are stretched too thin. Why is the QA lead suddenly very concerned with something that hasn't been touched in a while? Why are they putting you on it when you haven't touched it in a while? They must have a backlog of work, and it sounds like you are covering too many apps. Just MHO.
– LeLetterFeb 2 '18 at 23:13