Conducting a Sprint Planning

During Sprint Planning, the Product Owner and Scrum Team discuss the sprint goal and agree to the amount of work to achieve it. The Product Owner describes what needs to be achieved during the sprint while the Scrum Team assesses and provides feedback on the prioritized user stories in question from the Product Backlog.

The agreed-upon user stories are estimated based on the level of effort (from development to testing), then prioritized and tasked by the Scrum Team for the Sprint Backlog. If needed, the Product Owner provides additional clarification regarding the stories and their respective acceptance criteria. The Team then assumes responsibility for the work based on their experience levels and expertise.

Considerations

In order to finalize the sprint goal, there are several inputs that should be considered regarding the amount of work selected for a sprint. The Team should communicate their availability, as it may change sprint to sprint based on vacations, public holidays, and other responsibilities. Additionally, time should also be allotted for Scrum ceremonies as they reduce the Team’s capacity. Any constraints to the project or environment, dependencies, or the Team’s capabilities (i.e. technical skillsets) should also be considered as they directly impact estimates and overall velocity.

Once the Product Owner and Scrum Team select the user stories for the Sprint Backlog, the next highest priority items should be ready in the Product Backlog - either for the next sprint planning session or in the event the team has bandwidth to bring it in.

“Scope Creep” vs Adding Work

In the Scrum process, “scope creep” occurs when the Product Owner, or any other Scrum Team member, brings additional work (e.g. “gold-plating” or sneaking in Technical Debt) into the sprint without discussing it with the Team. The entire Team should always negotiate taking a user story out of the Product Backlog and bringing it into the current Sprint Backlog. However, if the Team has finished all of the work they committed to in the current sprint, and there is no way a developer can assist another or tester, they can raise the issue at the next daily stand-up and request to bring in new work.

If this continually happens, the Scrum Team may need to review their estimation and story pointing process.

Sprint Planning ensures the Product Owner and Scrum Team collaborate and negotiate the work for the sprint - not just aim for optimal “resource utilization” - as it creates a platform to communicate dependencies, identify the Team’s capacity, and further ensures daily productivity.

Good Reads

These are good references for conducting a Sprint Planning: