Scrum Primer - Sprint Planning

This article is part of a series on Scrum Primer. See the first post on Sprints

With all the hype on Agile and Scrum, one can easily misinterpret Agile to be against planning because one of its four values read - "Responding to Changes over following a Plan". Agile does subscribe to planning like every methodology, but the reliance on the plan is different.

Sprint Planning requires the Development Team to agree with the Product Owner on which Product Backlog items for an upcoming sprint.

Who - The development team, Scrum master (if your team is using Scrum), or the product owner.

When - At the beginning of each Sprint and only once for each Sprint.

Length - One hour per week of work. Sprint Planning should take approximately two hours if Sprints commonly occur over two weeks.

Flow - The Product Owner or Scrum Master works with the development team to create a Sprint Goal. The development team will pull the relevant Product Backlog items into the Sprint Backlog based on the goal. Next, the Development Team will jointly assign estimates to each Backlog Item, often referred to as Story Points. The Estimates are performed using techniques like Planning Poker or T-Shirt Sizing.

Outcome - By the end of the sprint planning meeting, everybody on the development team should know the end goal of the Sprint and what specific items are going into the sprint backlog.