When it comes to Scrum, Sprint planning is an essential part of the game. Therefore, being able to ace the Sprint Planning meeting is fundamental to delivering high-quality Project Management results.
So, what exactly is Sprint Planning?
According to the Agile Alliance, Sprint planning is “an event in the Scrum framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items”.
Understanding this, the Sprint Planning meeting is the first of the four ceremonies that are conducted as part of the Scrum framework, the other three being the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
The Sprint Planning meeting marks the beginning of the Sprint.
So, what are the objectives of the Sprint Planning meeting? This meeting is held to first allow the development team to inspect the Product Backlog items together so everyone knows what needs to be done. Secondly, the team voluntarily commits to completing a list of items based on their judgment, their velocity, and the Product Owner’s insight on what Sprint’s Goals should be. This empowers transparency because expectations about the sprint increment are clear to everyone involved. Lastly, this ceremony is a great opportunity for the team to adapt to the execution plan and ensure they meet expectations.
Who is involved in Sprint Planning? The Development Team and the Product Owner are required to attend. The Scrum Master is optional on mature teams.
When nearshoring, the Splint Planning represents a great opportunity to gather everyone together in the same “place” so that planning discussions can become more effective in ensuring that your highly skilled Scrum Team builds exactly what you need instead of efficiently building a product nobody wants.
The Sprint Planning meeting focuses on two main things:
- What is to be built during the Sprint?
- How will the team build it?
In order to decide what is to be built, the Product Owner must have a Product Backlog that is up-to-date. Then he presents his take on what the goal for the next sprint should be. In this general idea, the PO tells the rest of the team the features he or she wants to improve or added to the product. By doing this, the initial goal presented by the PO helps in the selection of the Product Backlog items to develop in the current Sprint. To speed things up, the PO should have all the items related to his Sprint Goal sitting at the top of the backlog. This is the best time for the development team to ask questions about the goal so risk and uncertainty are assessed properly.
Then, once everyone understands the Sprint Goal and everything that is at stake, the Development Team starts planning and estimating every item in the Product Backlog, from top to bottom, until enough work has been committed. Additional and more specific questions usually come up during this phase of the meeting.
Why does having sprint planning meetings make sense? Situations, conditions, and requirements evolve during the course of the project, therefore, Scrum provides this opportunity for adaptation at the beginning of every single sprint.
So, how can Scrum teams ace the Sprint Planning meeting?
There are three key aspects that can make or break a Sprint Planning meeting: 1) How self-managed is the Development team? 2) How transparent is the team’s progress to stakeholders? 3) Is “perfect” getting in the way of “good enough”?
Self-managed teams are all the rage in agile cultures but their importance goes way beyond the flexible schedule arrangements, game rooms, and offices with nerdy interior design (we do have all of that, by the way). The important thing about self-managed teams is the fact that they are eager to do the best job they can and do everything in their power to remove all roadblocks between them and success. Self-managed individuals are proactively learning about the product they are tasked to build, are very outspoken on everything they need. They collaborate with their teammates and are committed to consistently being more productive than the day before.
Having a great self-managed team is only half of the story. Collaborative clients are instrumental for successful projects. Mutual trust must be awarded for developers to count on their clients and the best way to achieve that is by being fully transparent on the project’s progress and setbacks. This makes expectations clear and mitigates the risk of surprises.
Finally, Scrum is a game of learning. We learn about the product, about the users, about the client and also about ourselves. This is a gradual process that happens over time so your worst sprint in terms of productivity will always be the first. The key here is how fast we can learn – and by “we”, we mean both the scrum team and the stakeholders. Understanding this, we make sure that perfect doesn’t get in the way of good enough.
