No Sprint Planning meeting will be the same, but I have observed some very practical steps to help you power through your sprint planning and ensure the essentials are covered.
- Iterations are 2 weeks in length. (adjust time boxes listed below if you do 1 week or 3-4 week sprints)
- Teams have some level of cross-functionality
- Product Owner is embedded in the team and in attendance
Sprint Planning Agenda:
- (15-30 min) Recap of current sprint
- What is done?
- What is left and why?
- (5-10 min) Prioritize any leftover items – The PO decides if left over stories should move to top of sprint backlog or sent back to the backlog. (Do not assume that because something was a high priority before that it for sure is a top priority again!)
- (5 min) Close previous sprint in ALM tool (Jira, VersionOne, Rally, etc)
- (15-30 min) Revisit estimates for carryover stories. (Look for TOTAL effort, not just remaining effort. This is key for establishing velocity)
- (5-10 min) Evaluate capacity of the team (check for PTO, training, etc)
- (90-130 min) Create the Sprint Backlog – Pull stories from the backlog to create the sprint backlog one story/task at a time.
- Break each story/task down to sub-tasks
- Estimate hours for each sub-task (optional)
- Quickly Re-visit the estimates for the stories after tasks are created. Still seem good? (Your estimate was first created in backlog grooming, now you’ve gotten more specific and need to make sure it still is accurate)
- Note: if the team is not yet highly cross-functional you will need to take a look and who these tasks might be assigned to. If you only have 1-2 people, a team with a specific skill set you do not want to create a situation where the rest of the team is blocked because they have too much work. If the team is cross-functional you do not need to assign anything to anyone other than the first task an individual will work on after sprint planning.
- (10 min) Fist of Five – Ask the team about their confidence level for the upcoming sprint items. Specifically, this is trying to gauge if they feel their commitments are realistic, and there is nothing blocking them out of the gates. If there are outliers take the time to discuss and adjust sprint forecast as appropriate. Remember, you can always pull additional items from the backlog should the team finish all items in the sprint backlog.
- 5 fingers: I am 100% sure we will complete everything this sprint.
- 4 fingers: I think it’s probable we will complete everything this sprint.
- 3 fingers: There’s a 50/50 chance we will complete everything this sprint.
- 2 fingers: I think it’s unlikely we will complete everything this sprint.
- 1 finger: I am 100% sure we won’t get everything done this sprint.
- (10 min) Create sprint theme/goals – This could be action items from Retro, or focus on collaboration, or some vision from the PO about a feature.
What do you think about creating the Sprint Goals before the Backlog is created? We generally have at least 2 future sprints in a state of planning at any time but I’m not sure where this practice originates but the client seems to feel it s a health metric above and beyond having a healthy backlog.
I love that idea. In many situations, I could see it being more valuable if the backlog is not already organized in such a way. If you have a team supporting multiple business partners this could be more challenging to do, but a good aspiration for sure!