At Cinchcast Tech, we spend a lot of time thinking about how to improve our development processes. One adjustment that our Director of PMO extraordinnaire Dan Alcalde have made to our scrum process is to use 'swarming'.
In swarming, a group aggregates together working on a same task, just like a swarm of birds migrates in a particular direction. For bigger tasks, instead of assigning the task to an individual developer, we have an entire team work on it. These big tasks can often be broken into smaller pieces. Also, a definition of Done for large tasks can be fairly extensive -- not only does the code need to be written, but documentation needs to be presented, unit tests developed, and demos given to stakeholders. In the past, when a single developer worked on a large feature during a sprint, he'd run out of time and skim on unit tests on documentation. By having an entire team develop a feature, each member of a team can keep the other member in check, do pair programming, and share the architectural knowledge.
The other technique we use is 'self-organizing teams', where teams form on an ad-hoc basis. Instead of assigning specific tasks to individual developers, we let each developer choose which task he wants to work on. When a developer finishes his tasks, he is free to select more tasks to work on (although nobody forces him to do so). Peer pressure enforces people to keep up with their team mates, and everybody knows how much everyone delivers.
To be fair, swarming mostly works for large tasks.
1. There needs to be a clear definition of Done that everyone adheres to
2. The user story needs to be complex enough.
For smaller tasks, we continue assigning them to individual developers and not being overly strict about when a task is considered Done.