Sprint Planning - The Benefits of Tasking

What is Sprint Planning?
Spring planning is needed for the team to negotiate which stories will be tackled within the sprint. This should be decided after reviewing the number of hours available against the number of task hours required. In addition to hours available, the team should understand their velocity/trends as well - but that's another blog altogether.


How is it done?
1. The Product Owner prioritizes the refined sprint backlog stories and clarifies requirements.

2. The team’s “Sprint Budget” is identified – this is the number of available hours the team has to work on during the sprint. Ideally, the dev team is allocated to working 6 hours per day, to account for meetings and other interruptions.

In my Deutsche Bank days, the team would write their names on the whiteboard (stacked, as rows) and the days of the sprint (as columns). Looking at the days, they would write a "6" within their row for all days they would be working at 100% capacity. If there were holidays, PTO, offsite training - those days would be shown as "0". We would count the number of all teammember hours available and notate that as well. 

3. Stories are deconstructed into tasks.

• A “task” is considered necessary if it must be done for that story to meet its acceptance criteria
• Tasks aren’t just for development. There could be tasks for manual testing, automated testing or design sessions. 
• There were times when they would write a task to accommodate one of the Definition of Done statements, so it wouldn't go unnoticed. 
• In a perfect world, tasks should be written as deliverables since they are measurable. Instead of describing what you’re going to do, describe what you’re going to deliver. 

As a Product Owner for this group, I taped & prioritized the printed stories / wireframes / gherkins etc. to the whiteboard. Before tasking began, I would review the stories one last time and answer any questions. From there, they would self organize into small groups and tackle the tasking for each of the stories. 

4. Tasks are estimated in hours.

• Keep them small and manageable. As a general guideline, each task should be broken down small enough to complete in less than 1 day (6 hours). 
• Advantages of small tasks: 
  • Easier to estimate.
  • Accuracy of estimates likely to improve (practice makes perfect!)
  • More measurable. 
  • Provides clarity during stand up on what work was completed (1 day tasks are either done or they are not!). We can visually progress as tasks continue to move through the process daily vs every few days.

5. Estimates are discussed and agreed on as a team.

6. Add up task hours and deduct them from the Sprint Budget. 

7. Commit to the stories the team knows they can get done. 

8. Identify several stretch stories just in case the team delivers early. 

My DB team was cross functional and "T" shaped. The developers were able to assist with testing as needed, which allowed them to truly own & swarm on work.  During the tasking part of this meeting, the Product Owner is not involved although she should be available for any questions that arise. Typically, the ScrumMaster facilitates this session with the team members. 

The end result of this session is for the team to:

• Understand the amount of work required to complete the stories
• Identify which stories they feel comfortable committing to
• Commit to the sprint (best case scenario - using the Fist of Five or Roman Voting technique for consensus)

Benefits of Tasking:

• It fosters upfront planning which:  
  • minimizes the potential need for rework. 
  • allows us to discover unknowns sooner rather than later.
  • allows us to identify potential roadblocks or bottlenecks. By identifying them up front, we can plan the sprint better.
  • mitigates risk.
• Keeps the team engaged in the whole sprint.
• Fosters collaboration between team members.
  • Team gets clarity into potential impacts to other features due to the discussions that evolve at the planning session.
• Uncovers gaps in the process or requirements.
• Junior team members are involved in the strategizing process – allows them to understand the thought process from some of the more senior developers.
• Offshore team members benefit by having access to the tasks needed to complete a story.
• By knowing the number of hours available, we can realistically commit to the appropriate number of stories.
• The team gains confidence in their commitments & delivering their sprint goals, coming out of the meeting.  
• Burn down charts are accurate.
• There is visibility into the work that is getting done – we can see tasks moving forward.
• Multiple developers could work on one story which means getting it through to done takes less time. You know - that thing called flow.
• Tasking allows for the “pull process” to work correctly (ie: tasks aren’t assigned; the team grabs their own tasks). This gives them a feeling of control and autonomy throughout the sprint. Sometimes this pushes them out of their comfort zone and challenges them. 

Challenges of Tasking:

• All teams would need to agree on the # of hours/day for team capacity
• Tasking is for the team, tasks aren’t meant to be scrutinized for anyone else.
• Tasking at a planning meeting takes time (up to 4 hours per sprint).
• Getting buy in from all the team members could be a challenge as well. One possible solution: start small. Take two team members to task out a story. Another option, at a starting point, is to only task stories that are medium --> large sized.