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 he may report at the daily standup, at the end of the iteration, the story is either done or not. This provides the necessary objective evaluation that might be needed to deal with team members who are less than fully engaged on the project, should it come to that.
A second advantage is that it causes each developer to gain a comprehensive understanding of the overall design of the system, since each developer will likely need to modify most or all layers of the application during the course of one or two iterations. Any given story may not include all architectural layers, but over time it's very likely a developer will gain experience in each piece.
This approach may also work better with teams who can't, or don't want to, collaborate very much. Each developer can focus almost exclusively on developing his story without too much interaction with the rest of the team. This is not the most desirable scenario, but could be appropriate. In particular, a team that is not co-located on a regular basis, or is separated by several time zones, might be more effective with this approach. It may also suit teams who are new to agile and have been used to working independently.
This approach, however, has significant drawbacks. By maximizing individual accountability, it effectively destroys team accountability. Together with the minimized necessity of collaboration, this approach eliminates most of the behaviors that make a team, a team. There is no real common goal or cooperation on a daily basis.
The "dedicated developer" strategy will reduce or eliminate architectural silos (e.g., only one or two developers understanding the back-end system) but introduces strong tendencies for silos built around particular features (e.g., only one developer understands how the order notification code works).
Because one developer is dedicated to one story, if the story is blocked, the developer is blocked. Similarly, if the developer is unavailable (due to illness, vacation, production emergencies, etc.), then the story will not likely get completed. It's unlikely that another developer will be able to come up to speed on the story in time to complete both it and his original one.
Finally, this strategy shares a weakness with the "ad hoc" method, in that many of the stories will tend to be completed right at the end of the iteration. It's also possible that several stories will be "almost done" but not completed. If the team has overcommitted, several developers may find they have bitten off more than they can chew, and subsequently all fail to complete their individual stories. Ideally, the team should have realized this, abandoned a story or two, and gotten the rest completely done. It's better to have, for instance, 75% of the stories completely done, and 25% not even started, than have all of the stories 75% done and none finished. The "dedicated developer" strategy does not accommodate this situation, and worse, removes any real incentive for a developer to sacrifice "his" story to help the rest of the team.
Strategy 3 - Story Swarming
Using a "story swarming" strategy, the team "swarms" each story in turn, seeing each one through to completion before starting the next. In practice, it's frequently not possible for all the developers to work on the same story, so there are generally two or three stories being developed at the same time, each by a subset of the team. This practice has many advantages and avoids most of the problems faced by the two strategies previously discussed.
Story swarming promotes team accountability very strongly. Although the entire team may not be directly involved in the development of each story, a large percentage of the team will be. This generally avoids the problem of a developer feeling that he is only accountable for delivering his own stories or tasks. Granted, the subset of the team not directly involved in a given story may not feel a strong sense of accountability, but enough of the team does that the concept is preserved. Additionally, by focusing on completing a story before moving on to a new one, this approach ensures that developers feel completely accountable for delivering the stories they do work on, rather than just completing the tasks they happened to sign up for. From this perspective, team accountability may be even stronger using this strategy than with the "ad hoc" approach.
Since several developers will work on each story, most of the benefits of "ad hoc" approach are retained. There are enough developers involved with each story to support practices such as pair programming, as well as avoiding architectural silos or silos around particular features. It requires a high level of collaboration among team members. This strategy also accommodates unexpected absences and similar events well; the other developers working on that story can generally complete it.
A key benefit of story swarming is that it avoids the problem of many stories being finished simultaneously at the end of the iteration. Instead, it provides a fairly continuous flow of stories that can be tested and accepted. There may be one or two stories that are finished at the very end of the iteration, but the rest have been completed earlier, giving QA and the Product Owner plenty of time to verify them. And since working software is the best indicator of progress we have, this approach can give a better picture of the iteration's progress than even a daily burn-down chart.
This approach also resolves the danger of several stories being almost, but not quite, ready. If the team doesn't complete its work, it's generally only one or two stories that aren't done, so this approach allows a more acceptable failure mode. It's better to complete 75% of the stories, and have no progress on the remaining 25%, than to be 75% done with all the stories.
It's also worth noting that there is little difference between this approach and the kanban approach to agile development . It is also compatible with iterationless approaches; story swarming accommodates very short iterations, and would accommodate variable length iterations easily, delivering one story per iteration.
The strategy is not without its weaknesses, though. By focusing exclusively on a couple of stories at a time, a team might fail to address a risky item on another story in the iteration until it's too late. For this reason, a team might want to "cheat" a bit by having a developer identify and address risky items early in the iteration - for instance, prototyping a new feature and sending it to the Product Owner for feedback -rather than swarming a story with the others. After addressing those items, he can rejoin the rest of the team in working on their stories. This is a natural behavior under the "ad hoc" strategy that should not be forbidden by an overly-strict application of the story swarming rules.
Story swarming is also vulnerable to a blocked story impeding the progress of several developers. Depending on the nature of the block, it's possible that the team could work around it for a while, and then leave one developer to continue trying to resolve it while the others worked on a new story.
Finally, story swarming is slightly vulnerable to the problem of slackers spending all their time "pairing" or working on trivial tasks. However, since the set of available tasks is restricted to just the ones on the story being currently developed, it's much easier to detect and address this problem.
Recommendations
Story swarming is a good default choice for many teams, since it mitigates the weaknesses of other approaches without incurring any unique dangers that can't be worked around, and provides the unique benefit of a continual flow of stories. This approach is suitable for most teams in most contexts.
Very mature teams may want to opt for the maximum flexibility and higher potential velocity offered by the ad hoc approach. These teams must ensure that team accountability maps directly to individual accountability, and establish a process to ensure that stories have enough time for testing and acceptance.
Teams in very special circumstances may benefit from dedicating one developer per story, although this strategy has significant drawbacks. It may be useful for teams that can't collaborate as much due to geographic factors, and for teams that are very new to agile. Aside from those situations, the drawbacks associated with this strategy make it less appropriate than story swarming or ad hoc task selection.
