Sprint Planning Meeting : Goals, Best Practices and Common Pitfalls

A Sprint Planning Meeting is the foundation of the Sprint whereby a designated Product Owner communicates the priorities of the Product Backlog (open business requirements) that will be pulled into the sprint for the work effort that the team will address.

Sprint Planning Meeting
Sprint Planning Meeting

What is a Sprint Planning Meeting?

  •  A Sprint should encompass no more than 30 days’ duration, and is typically limited to one or two weeks. 
  • The Sprint Planning Meeting will identify the sprint tasks for each team member and establish commitment to the goals of the sprint, in a collaboration between the product owner and the team. 
  • A good rule of thumb for a sprint planning meeting length is 1-2 hours for each week of the sprint duration.

Sprint Planning Meeting – Goals

  • Sprint Planning Meetings have specific purposes and goals.
  • Identify the roles of the Scrum Master and other team resources
  • Identify the velocity/capacity of team members (any vacations or limitations to team member availability)
  • Establish the Product Backlog Items (PBIs or stories) to be moved from the product backlog to the sprint backlog for action

  • Team agreement of the PBIs that will be completed and delivered to the product owner
  • Communicate the duration of the sprint (timebox)
  • Definition of completion requirements – what must be “done” for the product owner
  • During the sprint planning meeting all team members must evaluate the PBIs to be delivered and come to a consensus that they are achievable within the timebox of the sprint. This generates commitment to delivering those products at the conclusion of the sprint.

Sprint Planning Meeting – Best Practices

  • Leaders experienced in sprint planning meetings will yield the most effective results for the sprint and product owner. 
  • Product owners are charged with presenting their PBIs and priorities to the team.
  • Questions and solutions are openly encouraged without fear of egos or politics.
  • Estimates of the effort required to resolve PBIs are well thought-out and agreed to.
  • For PBIs that are extremely detailed, breakdown estimating into separate tasks to make better use of time and team resources.

  • Be prepared with more PBIs than expected to be accomplished in the context of the sprint, to allow for prioritization or tasks that may not contain adequate details for estimation by the team. Make every attempt to have each PBI well defined for the team’s review.
  • The sprint team needs to be cognizant that the scrum master is in charge of the meeting. 
  • Product owners are participants and contributors as are the other team members. 
  • Product owners should have PBIs prioritized in advance of the sprint planning meeting, to facilitate evaluation of tasks to be included in the sprint.
  • Be sure that all parties agree to the definition of “done”, so that there are no disagreements regarding what the deliverables are at the end of the sprint.
Sprint planning meetings may be more effective when broken into two logical sections:
  • Product owner presentation of the PBIs, including priority and business value. This includes the opportunity for team members to ask questions and clarify requirements.
  • Evaluation of the priorities and detailed discussion of how the resolution should be accomplished. This facilitates estimation of the work required to complete each PBI.

Sprint Planning Meetings – Pitfalls to Avoid

Some of the most common issues inherent with sprint planning meetings, and sprints in general can be reduced greatly by engaging experienced scrum masters and through participation in prior sprints:
  • Over-commitment – This can be generated by poor estimation practices or requirements that were mis-stated or incomplete. It may also be that team members’ participation levels were unavoidably reduced or not accurately forecast. This may result in PBIs that are not delivered as promised, which could be moved into a subsequent sprint iteration.

  • Under-commitment – Here again, inaccurate estimates may result in PBIs being in “done” status before the end of the sprint. Product owner and scrum master may determine that additional PBI(s) can be pulled in and completed before the end of the sprint timebox.
  • Blocks and impediments – Unexpected situations may occur that impair the planned work for team members, such as illness or other activity that makes a resource unavailable. Tracking such instances is important to the sprint so that they can be reported out in the sprint retrospective meeting. There are variations of blocks and impediments: a task block may keep a team member from working on a specific task, which can be discussed in the daily scrum. A general block makes the resource unavailable for any work on sprint tasks, which is obviously more critical to the sprint success.

Sprint Process and Follow-Up

Over the course of a sprint, daily scrum meetings are attended by team members for effective communication of status, a review of challenges, and solicitation of solutions and alternatives.

These daily scrums also keep product owners up-to-date on progress and any open issues and resolutions.

Following the sprint there are additional follow-up meetings:
  • Sprint Review – This is an opportunity to share “lessons learned” in order to improve future sprint efforts.
  • Sprint Retrospective – in this session team members present thoughts on the methodology utilized during the sprint and any alternatives toward how work could have been done more efficiently.  

The nature of this type of work is cyclical and efficient. Once a team adapts to a few sprint cycles, the time-saving nature of the process becomes apparent. 
Swapnil Wale

Written by

Swapnil Wale is an IT Professional based in Sydney, Australia with over 10 years of experience in technology and project management. He is a passionate blogger and focuses on project management and BRMS articles.


Post a Comment


© 2013 Techno-PM. All rights resevered. Designed by Templateism

Back To Top
Real Time Web Analytics