Patterns for Sprint Planning 

Here are some of the right ways to do Sprint Planning: 

  

One way to do Sprint Planning is to have the complete planning session in one go. Meaning, the whole scrum team can come together for sprint planning, The product Owner proposes a business objective, the development team identifies the items that will help the team achieve the purpose, and the whole scrum team comes up with the Sprint goal. All this in one sitting.  

  

Another right way is to split it. The whole Scrum team comes together. The Product Owner proposes the business objective and lets the team take over the planning. The development continues to brainstorm without the product Owner and creates a plan on how they want to achieve the business objective. 

Once the Development Team is ready with the plan, they invite the Product Owner again to get realigned and craft the Sprint Goal. The team could then re-negotiate the scope with the Product Owner if the goal and plan are not aligned.  

 

What's the frequency? 

Sprint Planning is the first event of the Sprint. It happens once every Sprint at the beginning of the Sprint. This is the critical event that allows the team to identify and commit to the purpose of the Sprint. 

 

How much time do you spend on Sprint Planning? 

Sprint Planning is a time-boxed event. For a one-month Sprint, it is time-boxed to a maximum of eight hours. For shorter Sprints, the time box is generally shorter. For example, for a two-week sprint, the maximum time for sprint planning may be 4 hours, and for a 1-week sprint, the time box may be of 2 hours.  

  

Because the sprint planning event is focused on the current Sprint, time-boxing helps the team remain focused on the purpose of the event and the current most important business objective. 

 

Who participates in Sprint Planning? 

The Sprint Planning is for the Scrum team to identify the Sprint Goal and create a plan to achieve the goal. So the whole Scrum team participates. If the team feels that Subject Matter Experts, Domain, or Technical Experts can help them make better decisions, they can be invited on a need basis. 

 

Who facilitates Sprint Planning? 

The Scrum Master facilitates Sprint Planning. This does not mean that Scrum Master conducts the event.  Instead, Scrum Master helps the team understand the purpose of the Sprint Planning event and focus on the outcome so that the team can perform the event within the time-box.  

 

Can Stakeholders and SMEs attend the Sprint Planning? 

Sprint Planning is solely for the Scrum Team to Craft the Sprint Goal and create a plan to achieve the goal. If Subject Matter Experts, or Domain and Technical experts can help the team make informed decisions, the team can invite them to participate in the event. 

 

When does the team re-plan the work if required? 

The team works on end-to-end implementation - which includes a functional application, technical implementation, etc., to create a working product increment.

If the scope of the work differs from the initial understanding, the team can collaborate and re-negotiate the scope of the Sprint Backlog with the Product Owner. However, the Sprint Goal does not change. 

  

The team may require to re-plan as well. If the team feels that a plan is not aligned to the goal, they can re-negotiate the scope with the Product Owner. 

Alternatively, if the team thinks that there is not enough work for Sprint or if the work is too much for Sprint - both based on the team's collective capability, the team can re-negotiate the scope with the Product Owner. 

 
Anti-Patterns 

When do you size the Product Backlog Items? 

Scrum doesn't prescribe how you estimate. The development team cannot size the Product Backlog Items if they do not understand it. The sizing of the Product Backlog Items is focused on understanding the requirements. 

If you try to understand the requirements of the current Sprint during Sprint planning, there might be unknowns that would crop up, dependencies, lack of clarity of requirements, etc. If this is the case, the team cannot "commit" to achieving the sprint goal.  

  

Hence, the sizing for Product backlog items is not a good idea during Sprint Planning but is done better during Product Backlog Refinement. 

  

Having said that, if the team gets new information from the product owner about the scope of the Product Backlog Item during sprint planning, they can change the size based on their refined understanding. But the focus of Sprint Planning is not to Size the Product Backlog Items. 

 

What happens if the Product Owner is not available for Sprint Planning? 

The Product Owner is responsible for making sure that the product we are building is the "right" product. This means we are building a product that generates value for the end-users. Sprint Planning Event is focused on what Business goal we want to achieve in the Sprint.  

  

For example, if the Product Owner is not available for the Sprint Planning, there is an absence of Business perspective and inputs needed to create the increment. 

The team may end up picking up the items that may not be the "most valuable" or the "highest priority" for the current Sprint. This would result in building the "wrong" product increment. 

This, in turn, will impact the trust and confidence of the Stakeholders because the product increment does not generate value for them. This ultimately leads to investments that may not yield the right returns.  

  

Hence the Product Owner needs to be in every Sprint Planning to guide the team to achieve the business goals and maximize the Return on Investment. 

 

If the team says we are spending too much time in Sprint Planning, what do you do? 

If anyone from the Scrum team expresses that they feel they are spending too much time during Sprint planning, an excellent way to work in this case is to voice it out in the Sprint Retrospective. 

The Scrum team can then brainstorm and come up with new ideas and action items so that they can be more efficient during Sprint Planning. 

  

For example, The Scrum team might be spending too much time due to a lack of clarity of requirements. Due to this, they have too many questions, and this may be taking a lot of time. 

An action item that the team can come up with is to have regular product backlog refinement sessions regularly. Or they can propose to have prototypes and wireframes that help them understand requirements better. 

 

To conclude, Sprint Planning is an inspect and adapt Cycle that helps the Scrum team to choose work that will help achieve the business goals. 

It essentially allows the team to collaborate to identify the goal and plan to accomplish the Goal-based on the business needs that are of utmost importance at a given point in time, keeping in mind the team's capability, business needs, and stakeholder feedback.  

This is just a speck of knowledge on your journey to becoming an expert in the industry. If you have any doubts or require career guidance, feel free to connect with our Industry experts and trainers for 1-on-1 coaching.