What is sprint planning?
For any project to be successful, planning is essential. The same concept applies to sprints. The planning stage before initiating a sprint is called sprint planning. It ideally occurs in the form of a meeting scheduled by the product manager. If done properly, sprint planning meetings help teams revisit the scrum methodology with a renewed sense of purpose and gain insights from previous sprints. This sets the pace for the upcoming sprint.
What happens during a sprint planning meeting?
Ideally, the product owner, Scrum master, and development team hold the sprint planning meeting to prioritize the product backlog with the initial set of features and any new requirements the team has received since their previous sprint. The product owner presents high priority user stories the team needs to work on next. The team then breaks down the user story into its technical details, discusses possible use cases, estimates the amount of effort required, and comes up with a version they can deliver in this sprint. Sometimes, the team will need to reiterate a feature from the previous sprint or add new requirements to the product backlog.
A lot of teams use planning poker to gamify their sprint planning process. It's solely the development team's decision on how much work they're going to take up and what those work items will be.
Why is it important to have a sprint planning meeting?
The main objective of a sprint planning meeting is to determine the sprint goal and the sprint backlog. By the end of the meeting, the team determines both of these objectives. The sprint goal summarizes the sprint's theme in just a sentence or two, so team members can report quickly and maintain a strong sense of direction. The updated sprint backlog gives the team a clear vision for the upcoming sprint.
Things you should figure out before your first sprint
Sprint planning is an essential event before the start of any sprint, but when you're about to begin work on a brand-new product or take on an existing one, there are some fundamental things you need to have in place before you start planning your first sprint.
Shared Vision and Strategy
A product vision gives your team purpose, a problem your product has set out to solve. Clearly defining this in the beginning will make sure everyone—developers, designers, sales, marketing, and support—can align their work accordingly.
Business Model
In addition to product vision and strategy, commercial products need a business model so they can make informed investment decisions. If you're developing software for a client, you'll obviously align it with your client's business values, so this is not relevant for an in-house product.
User Personas
If you don't know who you're building the product for, you can't build it correctly. User personas are critical to writing user stories because theyhelp you ask the right questions and get feedback from the right user groups, which is key in making your product relevant.
Realistic Product Roadmap
While it doesn't delve into specific features, a product roadmap can outline the major release dates and milestones, as well as what major product increments would be delivered with them.
Ideally, if you have all these in place, you're on your way to building a great product. It's important to remember that the vision and strategy you have here are very broad and don't talk about specific features or things you'll deliver. These form the foundation on which you should base all your product decisions. If you get these right, you can be confident you'll be able to adapt to any changes that come your way.
It's not impossible to build a product without a product vision and strategy. However, while the benefits these steps bring to the table may not seem apparent, a product built without vision or strategy will have trouble meeting user needs and competing with better-crafted solutions.
Best practices
Every team is different—so are their velocities
Velocities from your previous sprints are used to estimate the amount of work for the next sprint accurately, and they should be used for just that. However, it's never a good idea to start comparing different teams' velocities. Team wars might lead people to overestimate stories in order to bump up their velocities. That will end up being counterproductive by skewing the average velocity of your team.
Avoid "billiard ball sprints"
When you hit a ball in billiards, it strikes another ball and transfers its velocity to send the second ball rolling. As Mike Cohn describes in his book Succeeding with Agile, when you don't prepare for your next sprint, the start of your next sprint gets postponed by a few days. Or sometimes the second sprint starts in name, but the team is so unprepared to do the work of that sprint that they spend days learning what is expected. This can be avoided by spending 10% of a team's available time in every sprint preparing for the next one.
Break it down—estimation and planning
Developers (and people in general) don't like long meetings. Even worse, as they lose their attention or start to get restless, the meeting takes even longer to finish. So some teams split up the sprint planning meetings into two meetings: one for estimation and one for planning. This works for some teams, but some feel they end up losing more time when it's split into two meetings. But don't knock it till you try it—see what works best for your team.
Don't change the sprint goal
While agility is all about embracing change, Scrum has a strict rule against any mid-sprint change. Sometimes a high-priority requirement comes in the middle of a sprint or, more commonly, new information is revealed which makes the current sprint's work irrelevant. In that case, the team makes a call on how to proceed. If they decide to act on the new information, the current sprint is dissolved immediately and they start planning for the new sprint.
This decision is not as easy as it appears. Sometimes, teams ship a good-enough version either due to deadlines or how extensive the necessary work is. They constantly reiterate their stories to improve them.
Most often, teams are interrupted because the product owner or the stakeholders failed to think ahead rather than by critical information being revealed, says Mike Cohn. Barring rare instances, Scrum advises teams to avoid mid-sprint changes. People outside the team must understand there is a cost to redirecting the team.
Learn and adapt
Like all the practices in agile methodology, this must also be approached with an inspect-and-adapt mindset. Experiment with new ideas to make your team's agile planning process more efficient. Every small routine can have an impact and the whole team stands to gain from it. Scrum calls for the small feedback loops of reiterating and improving, over and over, and it's critical to apply this methodology to every part of the process.
To sum up
Agile sprint planning helps the team prepare before the start of every sprint. The entire team gets to weigh in on what work they're going to take up and together they come up with a sprint goal. Every meeting in Scrum has its own purpose and it's important to understand them in order to practice it effectively.
In Zoho Sprints, you can schedule all your Scrum meetings for your team and set up email meeting reminders and in-app notifications. Record your takeaways in the group chat so that you can take them up as actionable items after the meeting.