This is why it's good to have a ticketing system. At first, just create tickets yourself for the ad-hoc work (but make it visible to the requestor). I do this for anything that takes more than an hour or so, or for even miniscule tasks if it's a particularly busy time (just to keep track of everything).

If it's a larger request, then you can say "Sure, I'll fix it, but i'll have to stop working on TICKET-1234, is that OK?"

Eventually people learn to create and prioritize their own tickets.

This is also good because sometimes a "five minute" fix can turn into a huge project because of unanticipated factors.

Separate developer days into blocks.

A small block at the beginning of the day for an "open house" where anyone can directly ask questions of devs, come to chit chat, etc.

One block can be support tasks / ticket fixing. Contacting devs is OK here but it's preferred to be in the open house time.

Another block can be heads-down, planned development. Developers don't get bugged here unless there's an active fire burning. The plan should be set forth at the beginning of the week so there's no confusion.

We've been doing this for a couple of weeks (after a department reorganization) and it's been working pretty well.

It's important to get buy-in from the rest of the company on the idea that context switches are actively harmful to development. Joel Spolsky knows it[1]. Jeff Atwood knows it[2]. So do many others. But you have to get management to understand it, or you'll never escape from the constant "just a small fix" interruptions.

1. http://www.joelonsoftware.com/articles/fog0000000022.html

2. http://blog.codinghorror.com/the-multi-tasking-myth/

Might have to start saying no to clients, specifically "no we're booked for the week, but can get that feature request in for you next week".

Smaller things you can still do ad-hoc, just budget in a few hours per dev per day for them. If the dev doesn't use all that time, they can get their other work done faster.

Yes, this is probably the root cause. I guess fundamentally we can never get predictable if we don't schedule work.

The "trade this ticket X that ticket Y" is a good approach. I've done that too with _some_ success.

One problem is that we have multiple clients, so each doesn't care about the others tickets.

Scrum sprints deals with this. It helped us a lot in that regard.

Good idea.

It will probably take a month for us to determine our velocity, then we can predictably dish out points.

It will take much more than a month to begin to understand your velocity