I have heard of many groups that will finish Sprint planning by taking all tasks committed to by the team for the sprint, and assigning them out to each team member. Teams I have been part of have tried this (especially the first few sprints when new to Agile planning) as it felt like the logic last step of planning. How else is a team member to know what they would be working on over the next two weeks (or whatever sprint timeframe was chosen)?
The opposite would be to not assign any tasks to individuals during the planning meeting, but instead have the team members select tasks as needed. Having tried it both ways, I would submit the following:
Best Practice: Don’t allocate all Sprint backlog tasks to individual team members at end of Sprint planning meeting, but rather have team members pick tasks from the Sprint backlog as they come to the point of needing more work during the Sprint.
This seems counterintuitive to most, myself included. Questions flood to mind like:
- How will we be sure that the ‘right’ people do the ‘right’ tasks?
- Aren’t there specific tasks that only the ‘experts’ on the team should do?
- What about situations where someone has specialized knowledge regarding a specific task or set of tasks?
Not only questions regarding task allocation, but also about individual commitment and getting the work done come out. Not having a single person responsible for each task brings questions like:
- Who do we look to for assurance each task will get completed?
- Doesn’t this open up opportunities for some team members to slack since they aren’t individually responsible for specific tasks?
- What about those team members that need to feel the time pressure of a number of tasks in their work queue to work at optimal speed? (Many of us work best ‘last minute’)
Based on my experience, and that of others I have spoken with, many of these questions are more pertaining to the cultural shift from traditional Project Manager led teams, to self organizing Agile teams. Though you may have the fear that some people might slack, or tasks might not get completed during the sprint because they isn’t a single person responsible for each task, the actual opposite happens. By leaving the tasks in the sprint backlog to be picked from as the need for more work arises, the team collectively takes on the responsibility to complete all tasks, instead of just ‘my’ tasks in the other scenario. This has proven to be a much more efficient way to enable the team to ensure they complete the sprint goals and do it in highest priority order. Also, the daily standup meetings help ensure all team members are ‘pulling their weight’, as there simply is no way to hide if you are updating your team members each day regarding task execution/completion.
Certainly there are tasks that naturally go to certain team members based on their past experience/etc. But more often than not, the team members know of these situations too, and therefore it works out just fine and in those rare instances that it doesn’t, the team works out the situation as it’s identified and grows from the experience.
To ensure we consciously search for situations that could get us in trouble task allocation wise, teams I have been on have gotten into the habit of asking at the end of Sprint planning: “Are there any tasks in this Sprint that someone feels they MUST specifically work on?” Very rarely do we identify such tasks. When we do, we discuss as a team the reasons and decide if the task should go to that person right there. Otherwise, once the planning meeting is over, each team member selects a task (from their desk) they can ‘Race to Done’ on, and enlist the help of others on the team if they need such help.
For those people that work best ‘last minute’ and feel the need to have a large task list assigned to them, they can simply shift their focus from an individual work queue to the team queue and race to done.
The team can use the Sprint Burn down chart to measure how well they are doing completing the Sprint tasks/goals and adjust accordingly if the slope of the Burn down is showing Sprint goals won’t be completed.
Use of the Burn down chart enables the team as a whole to measure progress and adjust as whole while the Sprint is progressing. This in conjunction with the Daily Standups keeping communication open and bringing issues out quickly, really does work well and eliminates the need to assign all Sprint tasks at the beginning of the Sprint.
Next up in this series, the importance of Visual tools for Sprint planning.