Each and every sprint begins with a sprint planning session. Sprint planning takes place with the Product Owner (PO) and the Delivery Team. It’s the PO’s job to explain the purpose of the sprint to the delivery team, to help them understand how each of the stories fits into the objectives set for the sprint. That understanding helps them make decisions about how to approach stories, their implementation and to challenge requirements and assumptions too.
The planning session should be time boxed to 8 hours in total. If you finish in less time then give yourself a pat on the back. If you don’t finish in time it’s going to seem like a long day. Planning is an intensive day. You’ll learn a hard lesson and you’ll be far better prepared for the next session.
The planning session begins with the PO explaining the objectives of the sprint and then talking through each of the priority stories in the backlog. As each story is discussed the team questions the story, makes sure they understand what’s required and they estimate the effort required to complete the story. The stories continue to be taken from the product backlog and placed in the sprint backlog until the team is confident that they have enough stories that they complete within the sprint.
Depending on the circumstances the team might discuss the technical approach to each story while the client is in the meeting or they might choose to do this in a separate planning session. How this is handled will depend on the PO, whether they’re interested in the technical approach and whether they have something to add. Whatever your approach, keep to the 8 hour time box.
The team estimates the effort required for each story using one of a number of different methods. Generally, stories are compared with other stories to understand their sizes. It’s common to take an average story from the sprint backlog, assign it a 5 or medium and size all other stories against that. It’s not important what number or value you give to a story but we need to measure the effort. When you are estimating stories in the next sprint it’s worth taking a completed story from the previous sprint and using that as a size guide. Over time your estimates will become more accurate, particularly if the delivery team remains the same.
At the end of the planning session you should have:
A sprint backlog that all members of the team are confident can be delivered
Clarity on all stories in the backlog (don’t take assumptions or ambiguous stories into the sprint)
A closed backlog that the team will work on with no “just add this little story” backdoor editions to the sprint
The sprint objectives recorded in the sprint summary document