Iteration and release planning are keys to successful agile projects, but overall have a relatively small impact on a developer's day-to-day life, compared to the daily planning that takes place each morning. The strategy a team uses to sign up for work has significant implications for what a developer's day will look like, impacts his work style and habits, and ultimately can significantly impact the overall success of the iteration. Unfortunately, the agile community gives relatively little guidance in this area. In this article, I will share my experiences with three strategies for task allocation, drawn from several typical agile projects with two to three week iterations.
Strategy 1 - Ad Hoc
The simplest approach to selecting tasks is ad hoc. Any developer can sign up for any task he feels like working on that day.
This strategy has much to commend it. Since it maximizes flexibility, in theory this should provide the highest potential velocity. The team can sign up for work in whatever order makes the most sense. If a task is blocked for some reason, the ScrumMaster can take responsibility for removing the block, and the rest of the team simply picks up tasks that are not blocked. Higher risk items can be addressed earlier. Developers can choose tasks based on their energy that day, their interests, and any other relevant factors. It is also fairly easy to accommodate events such as unexpected absences by team members.
This method also supports a variety of good practices, such as switching pair programming partners frequently (at least daily), least qualified implementer, and collective code ownership. Few silos of knowledge about functionality or architecture develop, and when they do, it's an easy problem to fix.
Finally, this approach maximizes the idea of team accountability. The entire team is responsible for getting all the tasks done. We all succeed or fail together.
This strategy also has some potential weaknesses, which generally manifest themselves on less mature teams. Chief among them is the problem that a team member can easily slack off, either by "pairing with" (read: "watching") stronger developers, or by consistently picking up trivial tasks and exaggerating the time needed to complete them. While this is usually easy to detect, it's quite hard to objectively demonstrate the poor performance or unambiguously define the desired behavior - which makes it tough to manage. While a better approach to pairing will help detect or prevent this, a team may be better off with a strategy that makes it harder for slackers to hide.
A second weakness of this approach is the unfortunate tendency for many stories to be in active development at any given time. As developers move from one "juicy" task to another early in the iteration, it's very tempting to leave the less exciting tasks for later. Ultimately this causes many stories to get done at roughly the same time - about 15 minutes before the code freeze. This can overwhelm QA and the Product Owner, who do not have time to accept the stories or adequately test them. The resulting blame game during the demo and retrospective is anything but productive.
The third weakness with this approach is a flip side of its strength, team accountability. No single individual is directly accountable for much of anything other than his daily tasks. When everyone is responsible, it can work out that no one is responsible. This can result in a lot of stories that aren't quite finished, but nobody feels particularly bad about it.
Strategy 2 - Dedicated Developer per Story
Another strategy for signing up for work is the dedicated developer/pair per story. A developer, or a pair of developers (depending on your practices), signs up for a story and is responsible for seeing the story to completion.
If the ad-hoc approach is the most agile, this has got to be the least. It is the least flexible and destroys any real sense of team accountability. However, it is not without some strengths and other characteristics that might make it appropriate in certain situations.
One major advantage of this approach is that it provides nowhere for "slackers" to hide. Each developer (or pair) is responsible for seeing at least one story through to completion. Whatever status