This cheat sheet will act as a guideline for your next Sprint Planning Event.
In a nutshell
1. Understanding the product backlog
Review the items in the product backlog and prioritize them based on business value, risk, and dependencies.
Real life examples
Software: In an e-commerce company, the top priority for the next sprint could be fixing a bug that prevents customers from checking out and completing their purchases.
Hardware: In a hardware development company, the top priority for the next sprint could be to complete the design and testing of a new component that is critical to the functioning of the final product.
2. Defining sprint goals
Identify the sprint goal, which should be a clear and concise statement that guides the team during the sprint.
Real life examples
Software: The sprint goal for a project management tool could be to “deliver a feature that allows team members to assign tasks to each other and track their progress.”
Hardware: The sprint goal for a hardware development project could be to “deliver a functional prototype of the new component.”
3. Breaking down items into tasks
Decompose each item in the product backlog into smaller, more manageable tasks.
Real life examples
Software: Breaking down a product backlog item to “Implement a payment gateway integration” into tasks like “Research payment gateway options,” “Set up a testing environment,” and “Write code to integrate with the selected payment gateway.”
Hardware: Breaking down a product backlog item to “Design and test a new component” into tasks like “Conduct a feasibility study,” “Develop the component’s technical specifications,” “Create a physical prototype,” and “Conduct testing to validate the design.”
4. Estimating task effort
Assign story points to each task to indicate the effort required to complete it.
Real life examples
Software: A task to “Write code to integrate with a payment gateway” may be estimated at 8 story points, indicating that it’s a complex task that requires significant effort.
Hardware: A task to “Conduct a feasibility study” may be estimated at 2 story points, indicating that it’s a relatively simple task that requires minimal effort.
5. Assigning tasks to team members
Assign tasks to team members based on their skills and availability.
Real life examples
Software: A developer who is experienced with bluetooth low energy integrations may be the best choice to work on the task to “Write code to integrate the bluetooth connection of the app to the e-bike.”
Hardware: A hardware engineer who has experience with designing electrical circuits may be the best choice to work on the task: “Design the power supply circuit for the electronics component of our new e-book reader.”
6. Identifying dependencies and risks
Identify any dependencies between tasks and address potential risks that could impact the sprint.
Real life examples
Software: If the task to “Write code to integrate with a payment gateway” depends on the completion of a task to “Set up a testing environment,” this dependency should be noted and a plan for addressing it should be put in place.
Hardware: If the task to “Create a physical prototype” depends on the completion of a task to “Develop the component’s technical specifications,” this dependency should be noted and a plan for addressing it should be put in place.
7. Confirming sprint capacity
Confirm that the team has enough capacity to complete the tasks in the sprint and make adjustments as needed.
Real life examples
Software: If the team estimates that they can only complete 50 story points in a sprint due to capacity, they should adjust the sprint backlog to reflect this and ensure that they are not overcommitting.
Hardware: If the team estimates that they can only complete 10 story points in a sprint due to equipment availability, they should adjust the sprint backlog to reflect this and ensure that they are not overcommitting.
8. Reviewing sprint backlog
Review the sprint backlog to ensure that all items are properly decomposed, estimated, assigned, and prioritized.
Real life examples
Software: The team should double-check that all tasks are assigned to team members, that all risks and dependencies are identified, and that the sprint backlog accurately reflects the team’s capacity.
Hardware: The team should double-check that all tasks are assigned to team members, that all risks and dependencies are identified, and that the sprint backlog accurately reflects the team’s capacity and equipment availability.
By following these steps, the team can have a successful sprint planning meeting and be well-prepared to deliver high-quality results in the next sprint.