Sprint planning is typically an industrious, productive process. Teams refine the backlog, set a target velocity, select user stories for the upcoming sprint, estimate effort and define tasks. Done correctly, teams leave planning with clear sprint goals and a clean sprint plan. Feels good, right?
Despite all this planning, developers often leave planning without tasks assigned to them – and that can be a good thing.
For newer scrum teams, assigning tasks during sprint planning acts as something of a safety net – it’s reassuring to know who’s responsible for which items, and assigning every task can help ease worries that stories will get left behind. While this approach increases individual accountability, it sacrifices team accountability. After all, the team committed to certain stories together; they should share the responsibility for claiming and completing the tasks throughout the sprint.
While claiming tasks after sprint planning is recommended, each team must decide the best way to adopt assignment. Check out a couple ways your team can leave sprint planning with the best game plan.
Take It Easy
Wanting the feeling of security that comes with a fully assigned sprint is completely understandable, but it has its costs. It’s easy for teams to become locked into certain development hierarchies, skirting dangerously close to a waterfall mindset. Making Developer A always responsible for unit testing while Developer B only works on building database logic makes the team far less flexible. Your developers probably do have core competencies (hence the whole cross-functional team thing), and there’s nothing inherently wrong with task assignment based on expertise – just be mindful. The agile adage “responding to change over following a plan” should guide your team here.
That said, new teams may need training wheels to start. Mike Cohn of Mountain Goat Software recommends considering fully assigning tasks for a team’s first five sprints. For the next few, move to assigning 50% of tasks, then 25%, and eventually 0%. This gradual transition can help teams feel more comfortable with each other’s capabilities and commitments, and can drive home the idea that the team owns the sprint backlog.
Assign Single Tasks
Of course, many teams like to leave sprint planning and hit the ground running; claiming tasks can feel like an unnecessary barrier. Some teams get around this by encouraging each developer to choose a single task from each story at sprint planning, leaving the rest unassigned. This approach helps the team be far more flexible and encourages team accountability. If a task winds up taking longer than expected, you won’t have a developer suddenly underwater for the rest of the sprint. This also reduces any reluctance for developers to jump on a task that might not “belong” to them. Everything belongs to the team, and the team is responsible to complete the work forecasted in planning.
So, what do you think? Does your team leave sprint planning ready to rock and roll, or do you prefer a slow jam?