Just in Time Tasking vs Upfront Tasking vs No Tasking

This topic seems to come up all the time and the answer seems to change based on your situation. For the uninitiated let me give you some background on what I'm talking about.

If you are following the rules of good user story writing, then your stories should be business focused and represent what needs to be delivered. What it doesn't cover is "how" the story is going to get implemented. To cover this we usually create task cards which describe the technical tasks required to complete the development of the story. Some examples might be "Create a new database table to store the customer info", "Modify the x screen to include the new fields", etc.

There are essentially three main variations to tasking:
- Just in Time Tasking - when a story is ready to be picked up and worked on, the dev pair that picks it up sits down with the business analyst to review it, and then they brainstorm the list of technical tasks that will be required to finish it. Usually they will write each task down on index cards, but I have also seen cases where they are listed in the online tool which the team uses to manage the stories and iterations.
- Upfront Tasking - at some point in the very beginning of the iteration the entire team gets together and essentially does what the individual pair did above. This often takes place at the end of the planning meeting, and the team goes through all of the story cards for the iteration.
- No Tasking - the developers don't write down tasks at all. They probably will do some upfront thinking on the design, but in some cases they dive right in.

Let me start by saying that I'm no fan of No Tasking. This may work in situations where the story is very simple and the duration is very short, but in most real life situations this is asking for trouble.

The main benefits of doing the tasking session is to do the upfront design, and have some means of documenting it so others can understand the thought process behind it. We encourage frequent pair switching on my teams and the cards, while not useful by themselves for understanding the design, serve as a good outline to explain what's going on to a new person. The task cards can also be used by the dev pair and others to judge how complete the story is - as tasks are completed the task cards are marked completed.

Upfront tasking is often favorable because it enables the entire team to participate and become knowledgeable in the high level design. If there are going to be issues the team will know at that point and there should be enough time in the iteration to either resolve those issues, or if they are insurmountable then other stories can be swapped in instead. The downside in most cases is that it can be a very time consuming exercise. If your team is large there will probably be a lot of stories to discuss, and some developers may tune out after sitting in the meeting for a long time, thus negating the participation and knowledge sharing aspect. There's also the possibility that the developers won't fully remember the details when it come time to work on the story, even if they have the tasks written out.

Just in Time tasking is often a response to the issues mentioned above. After sitting through a couple of very long up front tasking sessions, the developers rebel and demand to switch to Just in Time. The developers are happy that they don't have to sit in a long meeting, and the managers are happy because the work gets started. The downside is of course the opposite of the upsides of upfront - only the pair that picks up the card is involved in the design decisions, when new members join the pair they have to be brought up to speed, etc.

I've tried a couple of variations to find a happy medium to all this. On my last project we did the upfront tasking, but timeboxed it at an hour and a half. Any stories that didn't get addressed in that session reverted to Just in Time tasking. We prioritized the stories based on a feel for how complex they were going to be, so that we usually addressed the most complex stories during this session.

Another variation was used when I had a team of about 20 developers. Because of the team size there were a lot of stories each iteration. Upfront tasking with the entire team was a painful affair, but issues arose as a result of Just in Time. So the solution we settled on involved the team breaking into smaller subteams right after the planning meeting. These subteams took a subset of the cards and did the tasking for those. The team was pretty good at breaking themselves up into these subteams, often switching people around mid-stream if other people were needed.

So, the answer to the question is that it depends on the situation. If you keep the issues above in mind, and are willing to try a variety of approaches, you should arrive at a method that works best for your project situation.