Defining Effective Tasks
During sprint planning, the team creates its sprint backlog. This backlog consists of the tasks necessary for the team to meet their commitment in fulfilling each product backlog item as part of it sprint goal. Especially with new teams, I have seen team members stuggle with determining how to define tasks in a way that will support Agile and Scrum values.
Here are some guidelines to help you define tasks that will be more effective during your sprint:
- Every day the team should see progress towards their sprint commitment during their daily scrum meeting. Make sure tasks are timeboxed or estimate in small enough durations to see that level of visibility. The goal is that each team member shouldn’t have more than one or two tasks that they are currently working on at any given time. I have found that tasks should be around a half day to not more than two days in length to satisfy these needs.
- Tasks should have a firm start and end time. This will help reduce the number of tasks that are in progress at any time. Tasks should reflect the order of how you do the work, with clear milestones of moving to the next piece of work.
- Tasks should focus on the approach of your work instead of just the activities. Activities such as “Design,” “Coding,” and “Testing” don’t show how each team member is making progress during the sprint. Those activities just tell me what you do in your job, but not how you are applying these activities towards the completion of your work. Be specific on what your estimate entails (“What modules are you testing?” “How are you going to build the solution?”)
- Estimates of each task should reflect the activities of what has been defined as “done.” Teams will identify those artifacts through their team’s definition of “done.” These artifacts do not need to be individual tasks as long as those that are taking on those tasks understand what needs to be completed to call those tasks “done.”
- Tasks should be understood by the entire team. While an individual can sign up to do a particular task, it is possible that the tasks may get picked up by other members, or that multiple team members may work together on a task. Talk about tasks for each backlog item as a team during sprint planning. Doing this may also uncover additional tasks by getting multiple perspectives from team members, and it’s one more reason to spend the time during sprint planning to define how the team—not just a group of individuals—is going to meet its commitment.
- Tasks should be used to determine what you are committing to as a team. This is the primarily reason why sprint planning takes on average a half day for a two-week sprint. You need to spend the time having a conversation on what the potential solutions are and how as a team we are going to go after that solution through incremental work. I have seen too many teams try to shortcut this process by defining “task templates” that are the same for every backlog item, only to spend a lot more time during the sprint trying to figure out what the real work is all about. You are not saving time, but only delaying what needs to be figured out before you start the work. You don’t need a perfect plan, but one that gives the team enough confidence that they can deliver on their commitment. Usually, three to four hours is enough time to get to a “good enough” plan.