“We do Scrum, but… 15 minutes will do to finish the Sprint Planning”
Are you serious? — episode 7
Here is a common practice:
At the start of the Sprint Planning the Product Owner opens the laptop which is showing the Product Backlog Items in Jira. The items are nicely ordered in priority. The team then discusses the availability of the Development Team members and the expected velocity for the upcoming Sprint. Based on that they all decide upon the items to be put on the Sprint Backlog. The tickets are moved to the Sprint Backlog and the Sprint is started. With this the Sprint Planning ends.
Does this look like an ideal Sprint Planning from a well-oiled machine to you?
I am not so sure.
- Does your team know why they are working on the selected items and why not on other items?
- Does your team have an idea how to work together to deliver the increment within the Sprint?
Let’s look at what the Scrum Guide says about the Sprint Planning:
“Sprint Planning answers the following:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?” — SG
The Sprint Planning consist of 2 parts. The practice as described above does APPEAR to cover the 1st part, but definitely NOT the 2nd part. Why does it only APPEAR to cover part 1? Well:
“During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.” — SG
Every Sprint should have a Sprint Goal — the Sprint objective— to inspect and adapt on the progress towards this goal. With a Sprint Goal the team can assess what items would achieve this Sprint Goal. One of the most important reasons to have a Sprint Goal is to allow the Development Team to work together on the goal instead of working separately on different items. The Sprint should not be about ticking off items, but about creating value. This is reflected in the Sprint Goal.
When the Sprint Goal is determined and the Backlog Items are chosen the Development Team can focus on the 2nd part of the Sprint Planning. Now they determine how they are going to build the functionality into a “Done” working increment. During this exercise the Development Team could come to the conclusion that they would have too much on their plate, resulting into negotiations with the Product Owner on the selected Backlog Items.
At the end of the Sprint Planning the Development Team is able to explain to the Product Owner and Scrum Master how they are going to create a “Done” increment with which they will achieve the Sprint Goal.
“The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.” — SG
The Sprint Planning is all about setting a Sprint Goal, determining which Product Backlog Items would help achieve the Sprint Goal and a plan to achieve the Sprint Goal. It is not about making a selection of the items to work on.
If you limit the planning to only making a selection of the items to work on you should ask yourself:
- Am I getting the most out of my team when we don’t know why we are working on the selected items?
- Will you work as a team or will you work on separate items individually?
- Is Scrum my framework of choice while I ignore a central piece of Scrum?
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
Join us on Slack!
We run a Serious Scrum channel on Slack. You’re all invited. Feel free to connect with us on Slack to share your thoughts. Also if you are interested in publishing in Serious Scrum.
Thank you for taking your time to read seriously.
My twitter profile is https://twitter.com/WJAgeling