A backlog of “bite-size” tasks in parallel to the “main” feature backlog?

Question

After over two years of working in a highly siloed, "lone-wolf" development department structure, we're adopting Agile SCRUM. Great. I like Agile; as a dev it keeps you focused, busy, and productive without having myriad stakeholders shoving project after project down your throat with the expectation they all be done yesterday.

There is, however, one aspect of moving to SCRUM versus our current "model", that I think people outside Development are not going to like in the slightest. That is their current ability to have us do small changes "while you wait". A large portion of our development is for in-house consumption only, and we're mostly all in the same building. So, it's been common practice for years for a department lead or manager elsewhere to come to the "codebase owner" of a particular application and ask for small stuff (sometimes not so small, but we're pretty good about not taking on three-week projects based on these "drive-bys"). Even our boss sometimes relays things brought up to him in this way. Very often, if we're working in the codebase in question at the time, we can simply pop up the source file, make the change, and run it with them looking over our shoulder to verify the change is what they want, before checking it into Subversion for inclusion in the next build.

With a basic Agile SCRUM methodology, these tweaks would either be logged as defects (we didn't meet a requirement specified in a story previously consumed) or new small stories (we met all stated requirements, but those requirements were incomplete, vague or incorrect, or they changed after delivery once the users saw the new features). Either way, the vast majority would be one-pointers at most if not zeroes, and of relatively low priority (the system is usable in its current state, but it would be so much cooler if...), making them unlikely to be brought into a sprint when working the backlog top-down.

This possibility was raised at a dev meeting as being a source of active opposition to our Agile process by other departments, who would see it as less "agile" than our current ability to make small tweaks on request. It's a valid concern IMO; the stakeholders behind the PO don't always agree on what things are most important, because they don't all have the same point of view, yet it's typically only the managers who make the final decision, and therefore their bias is the one that shows in the product backlog.

A solution was then proposed, which was tentatively called the "candy jar" (another term thrown out was the "gravy boat"). Small tweaks requested by the "little guys" in the various departments, that are not defects in an existing story, that are estimated by consensus or acclamation within the team to take less than one-half of a developer-day, and that would have an immediate, significant, positive impact on the user experience in the opinion of the end user, are put on a list in parallel to the primary backlog. They'd be identified as "stories", but would be kept separate from the primary backlog of "big" stories subject to prioritization. If, at any time during the normal progress of a sprint, we happen to be working in an area of the system in which one of these tweaks can be made, making the tweak trivial, we can bring the tweak into the sprint and code it alongside the larger story. Doing this must not jeopardize the completion of the larger story or any other committed work. The PO would also have access to this list, and if they were working on an upcoming user story touching the basic feature involving the tweak, they could fold it into the story as a requirement and then we'd meet the requirement as we would any other. This, it was thought, would make tweaks more likely to be worked on sooner than later.

This triggered the reaction among those of us with ScrumMaster training of "uh-uh". There is one backlog. Two backlogs introduces the question of which #1 item is really the most important, which list's items determine real velocity, and which of the two backlogs a story actually belongs in (any demarcation of size/complexity is going to have some cases that fall relatively arbitrarily to one side or the other). "Let the process work", we said; if the change really is significant to the end users, they'll make enough noise to get the department heads making time/money decisions on board, and it'll get bumped up into the dev team's consciousness toward the top of the backlog.

I thought I'd pose the question to the floor: In your opinion, would a parallel list of "bite-size" stories have value in getting small, useful but ultimately low-priority changes made faster, or is it overall a better decision to fold them into the main backlog and let the basic process govern their inclusion in a sprint?