Others have answered this reasonably (namely that Google has no one way to manage this process and it's really up to individual teams to self organize as works best for them), but here's probably more text than you wanted about specifically how my team handles it.
We have more or less a rolling set of goals/projects and individuals who own those. As projects move from in progress to something we're willing to attach the word 'done' to, the folks working on them either pick up the next best thing on the list (that is, the next thing on the list for which they're the best suited person to own it) or they find another project where the owner is looking for some help and pitch in. Engineers are mostly expected to self-allocate based on what we understand to be really super important rather than simply really important.
The projects are sometimes defined internally ("Hey guys, wouldn't it be neat if...") and sometimes externally; rarely do they have hard ship dates associated with them[0]. Additionally, individual components have moderately well defined ownership, although this can shift over time as people's interests change (for example, I currently own the virtual NIC presented to GCE guests, so I tend to end up on networking projects).
My experience is that (for us) this works fairly well. From time to time someone puts on their manager hat (someone who actually has direct reports, that is) and asks people to shuffle around a bit. My experience with this workflow has been uniformly happier than my time (prior to Google) working with sprints, story points, and rigid deadlines that always slipped anyway.
Again, this is not necessarily indicative of how Google works in general, and your mileage may vary. Also, we're hiring :D
[0]: There are targets to help with prioritization and dependency tracking, though.
