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.
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.
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:
Benefits of Tasking:
Challenges of Tasking:
Just an agile-dork writing about dorky agile things.