Sprint Planning Rules and Best Practices
Online Scrum Management
Agile Job Board
Agile / Scrum / Lean Resources
Like most everything in Scrum, Sprint Planning sessions should be time boxed.
Planning completed during the session should be sufficient to set the direction for the work for the Sprint, and not much more. Sprint Planning isn't a roadmap or a strategy discussion. Most teams find 4 to 8 hours sufficient for a 4 weeks Sprint.
The theme of the Sprint, and enough of the product backlog (the higher priority items, or the candidates for inclusion in the sprint) should be ready and published prior to the meeting. This is the responsibility of the product owner or the scrum master.
The team should have at least a day to review the product backlog (enough to understand what implementing each backlog item would require) and add technical-driven features for consideration.
The purpose of the Sprint Planning is to decide on the sprint committments, and ensure their content is clearly communicated .
The team needs to provide a quick estimate of each Product Backlog item, working in priority order, and once the 'bucket' for the sprint is full, other items need not be discussed in length.
To better estimate the stories in an agile environment, many teams use
Get Concensus on Sprint Goals
The Sprint goals will drive the story and feature selection, and set the tone for the Sprint themes.
Determine the sprint goals in advance, and achieve buy-in from management, but leave some room to incorporate on-the-spot product owner or team input. The buy-in process may raise clarity issues. Make sure the goals are clear and relevant.
more sprint planning rules
Buy the book that explains sprint planning best:
Agile Software Development with Scrum