Sprint planning meeting is a significant agile scrum event and must be conducted with utmost sincerity. It is not a “me too” event. Never do it just because it is prescribed by the scrum framework.
The general understanding of a sprint planning meeting is to plan the set of tasks that will be carried out as part of the sprint, assign tasks to the scrum team and set due dates etc.
It is just a very small part. The key idea and benefits of Sprint planning sessions are far more strategic than tactical.
At a high level you must cover the following aspects:
As part of the 2020 Scrum update, Sprint goal has gained further significance. Hence, defining and ensuring the team understands the sprint goal and how it contributes to the overall product roadmap and goal is a must.
Unless, the team rallies and is excited about the sprint goal you are not going to get their 100%.
It is the Product Owner’s primary task to ensure the sprint goal is laid out before the team at the beginning of the sprint planning meeting.
Tip: Make the sprint goal very actionable, concrete and crisp
Next logical step would be to identify all stories that contribute directly to the sprint goal and prioritize them.
This is where the teams collaborate on the identified stories, review them thoroughly, enhance or groom them if required.
Tip: One practical thing would be to hold an informal sprint pre-planning meeting where teams can review the stories, identify gaps or questions that can be addressed in the more formal sprint planning meeting.
This way the team has enough time to digest the sprint goal and the stories and be on top of their game to ensure they are all sorted for execution.
This is where the game begins. The primary input here is your team’s velocity. There are multiple story sizing techniques but go with what your team is most comfortable with i.e. story points usually.
In general terms 1 story point is taken as a range of 4-12 hours. Industry practice being 1 story point = 8hours.
Hence, based on your team size and their velocity pick stories that the team will be able to deliver successfully.
If there is scope for more, do pick stories that are relevant or must go next as part of the roadmap to utilize resource capacity for the sprint.
Tip: Try to restrict 5pointer stories to max1 or 2 depending on your scrum team size and past performance.
Well, stories need to be made actionable and what better way than to organize them into neat tasks and sub-tasks. Robust task management is key to providing the team clarity on the story and laying out the actions that will be required to fulfill the assigned stories.
The teams can define the estimated hours for these tasks, categorize them well with task types and labels for added clarity. And lastly, transparent assignment ensures all know who is accountable for what and when.
Also, the teams can link related tasks to provide full contextual information and lay out room for end to end task collaboration between the different tasks assignee.
Tip: Task types and label help identify feature development, enhancements or bug quickly ailing with task linking
Review inputs from Sprint Retrospectives
Every scrum event is deeply thought out and highly scientific in its approach. Sprint retrospectives have 3 very crisp and concise elements
The headlines say it all. At the end of each sprint, the team identifies, what worked well, did not work for them. This retrospection leads to incremental quality improvements and refinements in the planning, execution process and in the overall sprint deliverables.
Moreover, it is an open collaborative discussion where everyone’s feedback is welcomed and teams are more forthcoming in accepting the gaps and plugging them.
Tip: Do record outputs from each sprint retrospective, share with the team and never miss one!
We have clubbed the bug fixing and definition of done in to one as they go hand in hand.
First the definition of done or acceptance criteria. The DoD defines when a deliverable is acceptable and ready to be accepted as a product increment successfully.
The acceptance criteria must be reviewed and discussed well in the sprint planning meeting to obtain the team’s total buy-in and eliminate any understanding ambiguities.
Also, definition of done defines the quality parameters and hence bug management must be addressed before the increment is delivered.
Hence, according 15-20% of the sprint capacity for bug fixing is a good idea. Ideally, all work must be thoroughly tested, identified issues must be fixed before the final deliverable.
This way the teams are always cognizant of the quality parameters and focus well on their tasks.
Tip: Link all bugs to the relevant tasks and stories for quick identification
Sprint planning sessions provide a good view of the overall product roadmap and how the current sprint goal ties into it. The teams can clearly visualize how their work will impact as well as shape the product vision.
More importantly, it is a collaborative event where open discussions on the stories, their priority, sizing etc. are done which help refine the backlog as well as bring more clarity w.r.t the sprint and product goals.
If you may these sessions act like a quick SWOT analysis event as well and enhance team collaboration & productivity, provide better understanding of the sprint goal and strengthens overall task management and execution.
Thus, teams are furthermore motivated to bring their best game forward, build with quality and ship on time.
How do you conduct your sprint planning meetings today?
Do you have an active agile project management tool to collaborate with your remote teams for effective agile sprint planning?
Start today with a 14 day free trial of Orangescrum agile project management tool!