Sprint Planning
Sprints in Scrum should be planned in advance, and a team devotes a separate event to this.
During Sprint Planning, the team determines:
- the scope of work to be taken into the sprint
- how it will be completed
- the expected outcome
The entire team, along with the Product Owner, participates in Sprint Planning. The Product Owner sets the overarching sprint goal, while the team decides how it will be achieved.
How does Sprint Planning work?
First of all, the meeting requires preparation. The Product Owner or Scrum Master reviews the results of previous sprints and refers to the Product Backlog.
It also makes sense to consider insights from the Retrospective. For example, if the team agreed on changes to workflows.
Sprint Planning is conducted as a meeting. Experienced Scrum teams recommend allocating no more than one hour per week of the sprint duration.
Discussion
The participation of the whole team in Sprint Planning is essential. It fosters dialogue between the Product Owner and Developers. During the meeting, three key questions are discussed:
What is the value of the next sprint?
The Product Owner proposes or directly states the Sprint Goal. For example, to implement new functionality in the product or to launch a new feature. The “value” is the outcome that the sprint will deliver.
For instance, suppose the team is working on a client’s website. In previous sprints, the team prepared the visual design, deployed the site on hosting, and filled the pages with content. Technically, the product is already ready and provides certain value to the client. For the new sprint, the Product Owner sets a goal: configure integrations with third-party services. With these integrations, the value of the site for the client will be higher than without them.
What exactly will be done during the sprint?
Once the Sprint Goal is defined, the team creates a plan for achieving it. Essentially, the goal is broken down into backlog items (tasks) that will be addressed during the sprint.
Returning to the website example: the team plans integration work — selecting suitable services, accessing their APIs, building marketing campaigns on top of them, etc.
When planning a sprint, it is very important to realistically assess the team’s capacity and not overcommit.
How will the work be carried out?
The team decides on the approach to solving the tasks. For this, they turn to the Product Backlog. Items aligned with the Sprint Goal are further broken down into smaller tasks that can be completed within a single working day. These tasks are then moved into the Sprint Backlog.
Continuing the website example: writing integration code, testing on a dev server, deploying on the production site, etc.
What is important to keep in mind
There’s no need to plan a sprint “down to the minute.” The team should stay focused on the Sprint Goal and remain open to alternative ways of achieving it.
Before the sprint begins, the complexity of each backlog item should be estimated — for example, in Story Points or hours. For estimation, use Planning Poker.
