We start our day with the Daily Scrum and we start our Sprint with the Sprint Planning. Those are the two principal planning events in Scrum.
There is a certain magic in coming together as a team. In stopping for a moment to think about what to do next. In setting a goal and planning together how to accomplish it.
Today we will focus on how to make the most of our Sprint Planning Event. We’ll refresh what’s the input and output of a good planning session. And we will take a look at some common problems developers identify during planning. But first of all, we will see what the Sprint Goal has to do with our biology and dopamine!
Recently I read somewhere that there’s no greater inspiration than having a deadline! And well, there’s something about it. Atari’s founder, Nolan Bushnell says:
“The Ultimate Inspiration Is The Deadline”
For as much as we hate deadlines, they make us sharp and creative. They eat procrastination for breakfast — or so I say. Duke Ellington said, “Without a deadline, baby, I wouldn’t do nothing.” Would you?
I remember I was talking with a team once if they wanted to consider trying Kanban instead of Scrum. To my surprise, some developers told me they liked this feeling of a little pressure they put on themselves by the end of the Sprint. And then comes the feeling of accomplishment: “We did it!” It does feel good, doesn’t it?
This made me think about why we feel good when we accomplish our goals. And I concluded that biology itself helps us. We get a dopamine shot every time we accomplish something that we are meant to do. Dopamine’s purpose is for us to get stuff done. There is a video with a voice-over of Simon Sinek on YouTube “The Good life Chemistry” where he puts it greatly:
“This is why you must write down your goals! There is a biological reason for that. We are very very visually oriented animals! We have to be able to see the goal for us to biologically stay focused!”
This is why it is so important that before starting the Sprint, we stop for a moment, plan it together, and define the Sprint Goal that we want to accomplish. We need to write it down and put it on the wall next to the Sprint board. Well, in this day and age, our wall would be a virtual place like Confluence, Miro, Mural, etc. Someplace where we can see it.
Now we understand better why it is important to set the goal and why a deadline can help us not only accomplish it but also feel good about it. Let’s move on to the actual Sprint Planning. What are the elements of a well-planned planning session?
Sprint Planning can be divided into two parts. The first one is for deciding what goes into the next Sprint and setting its goal. The second one is about deciding how the team will accomplish the Sprint Goal.
In the first part, the whole Scrum Team decides which Product Backlog Items (PBIs) to choose for the next Sprint. This way they will move them from Product Backlog that is owned by the Product Owner to the Sprint Backlog. And their ownership moves to the Development Team.
The input for part 1:
- Refined and organized Product Backlog.
- Team capacity in the past Sprints and team availability in the next one.
Input for the first part is the refined and organized Product Backlog. However, the Product Owner can also bring a draft objective they want to achieve in the upcoming Sprint. It’ll help to keep the meeting focused.
To decide what can be done, we need to know the capacity of the team based on the past couple of Sprints. It can be the velocity of the team or the throughput, i.e. the number of items they deliver per Sprint. Moreover, we need to know the availability of the team members in the next Sprint. Vacations or anything that might decrease their availability should be taken into account. It’s all based on experience hence the empiricism.
The output of phase 1:
- List of Items to be pulled into the Sprint Backlog
- Sprint Goal
By the end of part one, the whole team crafts the Sprint Goal to provide focus and direction during the Sprint. So the Product Owner brings a draft of the objective to the meeting. Afterward, the Development Team decides how much they can do in the Sprint and agree on the Sprint Goal.
This part usually takes around 1–2 hours for a Sprint of two weeks. Depending on how well the Backlog has been refined and known to the team.
The Development Team self-organizes to decide how those planned work items will be accomplished by the end of the Sprint. And they decompose them into small units of one day or less. The Definition of Done helps determine when the user stories are considered completed. They can ask the Product Owner for clarifications and make trade-offs if needed.
The input for phase 2:
- Product Backlog Items (PBIs) selected to become the Sprint Backlog.
- Definition of Done.
The output of phase 2:
- Sprint Backlog decomposed into small tasks.
- A plan to accomplish the Sprint Goal.
Sprint planning can take up to 4 hours for two-week Sprints. And respectively more or less for longer or shorter Sprints. Usually, though, it takes less time.
I asked a few developers about some common problems they see with the Sprint Planning and how to fix them. Here are some anti-patterns from the front line:
- Surprises — the developers are not fans of getting surprised on the Sprint Planning with new PBIs. There can be a bug or two that the team hasn’t seen before. However, to improve the planning and decrease its complexity, the team should work with the Product Owner to make sure all the PBIs have been refined before the planning.
- No Sprint Goal — or setting a sprint goal and never mentioning it again. When it’s not clear what’s the sprint goal then everyone does a different thing or new things are being added to the sprint and the team loses focus. Not to mention the loss of the dopamine rush and the eagerness to get things done!
- Not paying attention — planning can be an exhausting mental exercise and it is easy to get distracted and lose focus. This can result in poor planning and failing to consider if the team has all they need to meet the Sprint Goal. Feels a bit like a deja vu from the article about Daily Scrum anti-patterns. Offer to take a break whenever you notice the team is tired and the meeting stops flowing as it should.
- Confusing forecast with commitment — back in 2011 the word “commitment” was replaced with the “forecast” in the Scrum Guide. Now it says “The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment”. The idea was to remove the duty and obligation the word “commitment” entails. And bring the word “forecast” that is more suited for a complex environment where a lot is unknown. The team does their best to meet the forecast but they don’t need to commit to what they cannot predict.