Optimizing the sprint planning time

We all know that all the scrum events are time-boxed. Going by that, we have sprint planning time-boxed for a maximum of 8 hours for a 1-month sprint–the highest of all the scrum events.

The sprint planning has the maximum time-box – does it mean sprint planning involves lots of activities to be complete within the time box?

Let’s have a quick look at the scrum guide on the Sprint Planning

“The Input to this meeting is the Product Backlog, the Latest Product Increment, projected Capacity of the Development Team during the Sprint, and past performance of the Development Team”

The Scrum Guide calls out the below three as an ‘input’ to this meeting

1.     Product Backlog

2.     the latest product Increment

3.     projected capacity of the Development Team during the Sprint

Can we rephrase ‘INPUT’ and call it a ‘PREREQUISITE’ for the meeting?  Well, when a team considers these inputs as a prerequisite, then we get the answers for how to optimize the time taken for the sprint planning.

Just to add more details -  the sprint planning primarily answers the below

?                What can be delivered in the Increment resulting from the upcoming Sprint?

?                How will the work needed to deliver the Increment be achieved?

To get the above questions answered, the team has to be focused more on the actual planning and not on the backlog refinement. But unfortunately, many times teams end up doing the refinement part of the sprint planning. The major disadvantage of refinement during planning is that the team’s focus is on multiple areas.

Refinement itself involves a lot of actions like adding detail, estimates, ordering, reviewing, and revision. The team gets the PBIs ‘Ready’ for the commitment during refinement. Now, when the planning starts with the backlog refinement, the team spends much time on the refinement which results in a LONG sprint planning session.

 If the backlog health is well maintained, through ongoing refinement, the team can directly start committing the PBIs and the planning can be very effective.

Does that mean refinement is not be done during the sprint planning? No, it’s not that. The team can do refinement for a new user story which is identified during planning. But it is advised not to make it a practice to do refinement for all the user stories during planning or combining refinement and planning.

The team can very well revisit the refined user stories and make some changes to the estimation or add details, only if required. Otherwise, the team should start committing/moving the user stories to the current sprint based on the priority and proceed with creating subtasks, defining the sprint goal, etc.

The major advantage of having the Product backlog with PBIs ready/prioritized is that we maintain the focus on the planning activities. The second advantage is that the team spends lesser time during sprint planning.

Okay–now that we have looked upon the refinement, there is one more input mentioned in the Scrum Guide which is the capacity planning. Yes, the team is expected to have their capacity(in hours) planned in advance so that as the user stories are committed, the allocation can be done right away. The team need not spend time on discussing resource availability, planned leave, Holidays, etc.

=> Here is how the planning will look like when refinement and capacity planning is part of sprint planning:

Adding detail, estimates, ordering, reviewing, and revision of user stories; planning capacity - checking resource availability, planned leave, Holidays, etc; and then define sprint goal, start committing user stories to the sprint, tasking, and allocation

=> With prerequisites already in place (refined PBI and capacity planning) :

define sprint goal, start committing user stories to the sprint, tasking, and allocation

Doesn’t the latter look better?? Please share your thoughts..