As almost all developers will know, in a commercial development team, work is handed out in the form of tickets. Each ticket, in my view, represents a single piece of work and no ticket should cross the streams (or subsystems.) ie; the ticket shouldn’t contain requirements for changes to both the code and the database, as this is, in my opinion, two separate tickets that are related to each other (or, the code ticket depends on the database ticket – see the logic?)
Up until recently we’ve been assigning tickets to devs and discussing with them which tickets are next on their list, going by priority, ticket-type etc. Whilst this worked in some cases, in others it didn’t as the priority wasn’t clear enough and developers tended to cherry pick the best tickets first, as opposed to the most important, or they hadn’t written them down or something else came up that was more important and the list was thrown out the window.