Data driven Sprint Planning - It's time for predictable sprints

Sprint planning is an event in scrum that kicks off the Sprint. The purpose of Sprint planning is to define what can be delivered in the Sprint and how that work will be achieved. Sprint planning is done in collaboration with the whole Scrum team.  In our research with hundreds of leading Agile companies, we found that Sprint planning can be divided into four main steps:

1. Backlog refinement and setting Sprint goal
2. Capacity planning
3. Estimation
4. Task assignment

1. Clarify team and other resources availability. Is someone on holiday? Are there public holidays during the Sprint? Do we need special advisors to be booked? Physical resources?
2. Refine backlog items for the next Sprint one by one. Make sure the backlog items are ready to be worked on. Each backlog item should tell a story. It should focus on the problem statement and not the implementation. Moreover, it should have well defined acceptance criteria of what success looks like from a business point of view. 
3. Agree on a Sprint goal. The Sprint goal describes an overarching business goal for the Sprint. It explains why selected backlog items are being implemented and allows us to negotiate the scope of a Sprint if something proves more complex than expected. A Sprint goal should be actionable, complex, and challenging. If it is too easy and simple to achieve, it would not be motivating enough for the team.
4. Document the decisions. It is essential that all the decisions made in the Sprint planning meeting are noted down and documented. This will serve as a reference point for all team members. It is vital to keep all the documented points in one central place that can be accessed easily by each team member. 

During the Sprint planning Scrum meeting, the Product Owner is responsible for setting the goal or objective of the Sprint. They will also need to determine which of the product backlog items help contribute toward that specific goal. Each Sprint goal should seek to improve the product’s overall value to the user. The development team collaborates with the Product Owner to create a viable Sprint plan based on the goal. Once the Product Owner and Development Team agree on the chosen backlog items, the Sprint can then get started.

Sprint planning involves every Scrum team member—the Scrum Master, product owner, and Scrum development team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.

The general rule is that Sprint planning should take no more than two hours per week of Sprint duration. For instance, if your Sprint duration is 2 weeks, the meeting should take around 4 hours. However, if the Sprint duration is 1 week, then the meeting should take around 2 hours.

The Sprint should have a well-defined goal. This will help the team stay focused throughout development. The Definition of Done eliminates goals like high-quality work, meeting all acceptance criteria, or delivering all backlog items. Think about users and see how users can benefit from the outcome of the Sprint.

Moreover, avoid overloading the team's capacity. By nature, humans are incapable of estimating future events and how much time is required to complete a task. This is due to the Planning Fallacy, which explains our irrational tendency to overestimate our ability to complete tasks. Plan with a moderate margin of safety; give your teams a set percentage of time to adapt to these changes without sacrificing the completion of their work.

Sprint planning is probably the most significant event in the Agile life cycle. Without it there is no goal and thus value doesn't get delivered to the users. Sprint planning is imperative for setting the team up for success with clear goals and expectations. Good Sprint planning will ensure the team is aligned, working towards a shared goal and with higher motivation. It will also help the development team get ready for the future, forecasting challenges and giving a chance to set assumptions, align priorities and dependencies.

If Product Owners or Scrum masters don’t take the time to schedule upcoming work, team members may have a hard time understanding what they each need to focus on—especially if there are any dependencies between current and upcoming tasks.