Why Sprint Planning Should be Iterative
Why Sprint Planning Should be Iterative
Sprint planning is the starting ceremony of every sprint. As in every beginning, people want to dream about the goal, think about how to overcome challenges ahead and believe in each other to reach that goal. Sprint planning is a great chance for those activities.
However, Teams Struggle in Sprint Planning
Think about a team working with three-week sprints. That means, the team has a maximum of six hours for sprint planning.
Consider this scenario: The product owner has worked hard to create well-prepared and prioritized user stories. She was confident that team members would love the user stories and can’t wait to start working on them.
When the team starts to listen to the first few user stories, they start to ask questions and give feedback. Some questions make some user stories not meaningful anymore. The product owner is getting frustrated because she has four or five hours left in the sprint planning and she needs to rework some issues to clarify.
So sometimes, she starts to assume instead of discover. Sometimes she has to abandon a user story. Sometimes she defends the user story against the team even if she agrees with them, and that damages the motivation of giving feedback.
Then, things get worse. Team members estimate user stories. The product owner sees that some of the top-prioritized issues are estimated as the biggest ones. She has to rethink prioritization by a return-on-investment approach.
Close to the end of planning, team members get tired. They tend not to think or question that hard. They just estimate to finish the session and want to go back to their desks.
The single biggest goal of sprint planning is in danger: shared understanding.
Sprint planning is a linear activity and it’s driven by the PO’s plan. If something is wrong with the plan or prioritized user stories, it’s nearly too late to adapt and change. That’s why I think we can make the sprint planning activity more like the iterative approach so that we can inspect and adapt.
Here is how our team made it iterative, and what worked and what did not.
How to Create Iterative Sprint Planning
First, we organized the six-hour sprint planning activity as a six separate, one-hour sessions. If we can do backlog refinement meetings, we actually don't need all of those six hours, because some of the product backlog items were already reviewed by our team in backlog refinement meetings before sprint planning.
In every session, the PO brought a small list of prioritized user stories to fit in one-hour sessions. The product owner was comfortable and excited to get feedback, because she had enough time to review it.
Team members were also comfortable to ask hard questions. At the end of the session, the product owner returned to her desk with some estimated user stories, but mostly user stories with question marks.
In the next session, the product owner brought again a small list of user stories. Some of them were new and some of them were the user stories with questions, hopefully answered, from the preceding session.
At the end of every session, the team has a healthy "shared understanding" about the product increment they will build in the sprint. Also, the sprint goal is starting to appear.
This approach worked for us with one, single problem: sometimes, reserving a six-hour meeting is easier than reserving six one-hour meetings. However, when people in the organization started doing shorter, more effective meetings, finding a one-hour meeting became easier.
Commitment Requires Shared Understanding
You know what they say: “Garbage in, garbage out.” If we think of sprint planning as an iterative activity instead of a one-time shot, we can build a shared understanding incrementally by inspecting and adapting.
Teams may start sprints confidently and that means real commitment.
Özmen Adıbelli works as a Scrum Master at Pegasus Airlines. He focuses on keeping teams going in their agile journey.Learn More