Some teams treat their Sprint Backlog as a 'Sprint specification document'. When they start a sprint, they begin by exhaustively identifying and estimating all the individual tasks that are necessary to complete a user story. This results in Sprint Backlogs with overly specific tasks such as 'write stored procedure for X', 'set up class design for Y', or 'implement and style button Z'. Sometimes, tasks are also distributed within the team, before any work has actually been done.
Although this approach gives the team a (theoretical) sense of understanding what needs to be done, it also means that they are implicitly making a lot of decisions about design, architecture and execution upfront. This will impede the team's ability to creatively and pragmatically make on-the-spot decisions during the sprint and self-organize accordingly. The power of a more on-the-spot approach is that it allows a team to take into consideration the available time left in the sprint, team capacity, technological knowledge, experience from the sprint itself and other contextual factors. It also makes the Sprint Planning sessions a lot shorter and more effective because less time is spent on predicting potential tasks (that may or may not actually be relevant).
So, I prefer a more ad-hoc approach. Instead of splitting up user stories into detailed tasks at the start of the sprint, teams identify and distribute tasks when the user story is actually picked up for implementation during the sprint. The most convenient time is after a Daily Scrum, when a new user story is picked up. At NowOnline, this usually involves the whole Development Team (or available developers) gathering around a whiteboard (preferably) or sitting together to determine how to implement the user story. We sometimes call this a 'Code Preview' (although 'Design Preview' may be a better term). Immediate tasks are identified and distributed, but new tasks can be identified and added throughout the sprint. Tasks are not assigned, but developers either pick them up during the Daily Scrum or during the day, when they are done with other tasks.
This on-the-spot approach puts more power to the team to self-organize in such a manner that it can most efficiently attack a user story. It is far more fulfilling for a team to experience that it can 'take any challenge' without spending a lot of 'Think Time' upfront (which is actually unnecessary in most cases). It also helps a team to develop much-needed communication and decision-making skills by working together closely.
As always, there exceptions:
- New teams: Teams transitioning from a waterfall approach will probably lack faith in their own ability to make on-the-spot decisions and may not have the level of communication- and/or decision making skills. For these teams, it may work to gradually adjust the level of detail that goes into task-specification throughout a few sprints. After all, these teams are used to receiving very detailed specifications and working through them. They don't have experience with another approach. It would be unfair and unwise to shock them into a new process. But both the team and the Scrum Master should keep in mind that this approach impedes actual Team Agility and should only be used as temporary 'training wheels';
- User stories with external tasks: Sometimes, user stories involve tasks that can only be completed by or with external parties. For example, getting hold of an external DBA to configure a database or getting an SSL certificate. If these tasks completely or partially fall outside the team, they can be identified at the start of the sprint as tasks for a user story. This allows a team to remain aware of these impediments and plan accordingly;
- If the teams considers it necessary: As always, the team should adjust its process to the problem at hand. If that problem is so complex that it is beneficial to spend more 'think time' upfront, then do so. But it should not be the default approach to all user stories;
In short, I would advise a 'Just-In-Time design' approach to user stories as well. Don't over-analyze a user story at the start of the sprint, but trust in the team's ability to 'solve' the user story when it gets to it. It all comes down to trusting the team in their ability to gettings things done.
So, what do you think? Do you agree with my observation and advise or not at all? Let me know in the comments below.