post photo by pexels
Introduction
This post is the second part of the "Scrum events demystified" post series. You can find the first part here:
In order to successfully execute the Scrum tasks and maximize the Increment value, a team needs to pay attention to the chronologically first Event in the Sprint; The Sprint Planning event.
About Sprint Planning
Sprint Planning is a time-boxed event (as all events are in Scrum).
Time-boxed means that it has a predefined, specific time span,
and should start and end exactly when this period dictates.
For example, the team might agree upon having one-month Sprints.
Other teams might be more comfortable and productive with 2-week Sprints.
For 1-month Sprints, the Sprint Planning event should be 8-hours long.
Who should attend the Sprint Planning event?
Everyone (Product Owner, Scrum Master, Development team).
The Sprint Planning event's goal is to address the following topics:
Selecting the work to do in the Sprint
The product owner explains the backlog items to the Development team.
The development team determines the number of backlog items that will be brought into the Sprint BacklogPlanning how the sprint work will be done
The Development Team does this. The Development Team needs to only do necessary planning work for the first few days of the Sprint. As the development team analyses the work they selected from the backlog, they can renegotiate the work with the Product Owner.
Ideally, the Sprint Backlog tasks are decomposed so they can be finished within a business day.
During the Sprint Planning event, the Development Team is supposed to construct the Sprint Backlog, a collection of tasks that will be owned and developed by the Developers.
According to the Scrum Guide:
"The Sprint Backlog is a plan with enough detail that changes in progress can be understood at the Daily Scrum”
Most common questions and misconceptions about Sprint Planning
Why is Sprint planning important?
- Sprint Planning is important because the outcomes of it are the Sprint Goal and a plan of delivering the Increment. Both the Sprint Goal and -of course- the Increment are integral parts of the product development process and define whether the product will be successful or not.
Should the Sprint Backlog remain intact after Sprint Planning?
- No. The Development Team modifies the Sprint Backlog throughout the Sprint, And the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the Sprint and gains more knowledge about the work.
Should the tasks in the Product Backlog be User stories?
- No. Actually, the tasks in the Sprint Backlog can be expressed however the Development Team desires, as long as they are clear and communicate the work to be done.
How are the Product Backlog items prioritized and by whom?
- In Scrum, The Product Owner is responsible for maximizing the value of the product and they manage the Product Backlog as such. During Sprint Planning the Product Owner suggests the objective of the upcoming Sprint and proposes which Product Backlog Items will help achieve this objective. So, the items in the Product Backlog are ordered by value. The most important ones go at the top so that they are selected for the next Sprint Backlog.
Does the whole Scrum team agrees on the estimates for a task?
- No. Only the development team creates estimates, which can, of course, be communicated with the other stakeholders (Product Owner and business stakeholders), but in no way negotiated with them.
When a task is assigned to a developer, are they solemnly responsible for it?
- No. All tasks in the Sprint Backlog belong to the whole Development Team and the whole Development Team is responsible for them.
Is the Sprint Backlog just a collection of tasks selected from the Product Backlog, to be done in the current Sprint?
- No. The Sprint Backlog also contains a plan of how the work will be done. It might contain tasks, sub-tasks, notes, and development guidelines.
Conclusion
In conclusion, the Sprint Planning event is a time-boxed event, during which the Scrum Team discusses the next Sprint, it's goal and how this goal will be achieved. The Product Owner prioritizes the user stories in the Product Backlog and the Development Team picks the user stories and creates estimates for them.
The team discusses in more detail how they will deliver the selected product backlog items. This may (but does not have to) include identifying tasks for the product backlog items, whether there are any dependencies between the items, and discussing the technologies or development paradigms that will be utilized.
In this series, I will be clarifying all Scrum events and demystifying the most common misconceptions about them.
Please share your thoughts in the comments, and stay tuned for the
next part of the series!
Top comments (1)
Interesting article!
I would like to mention something which is in many cases not easy to define: the spring goal.
The problem I have always had is how to convince the team to define a clear sprint goal especially in later sprints of the release, where there are tasks related to bug fixing.