I’m not claiming to be an expert here but when kicking off a sprint, it is important that everyone in the team is aware of what is needed to be ‘successful’ in the sprint. When going into the actual planning meeting, the sprint team needs to have:
- A fully prioritised backlog
- User-stories which fit into sprints
- Acceptance criteria for all user-stories
The idea of the pre-planning is to make sure the team is as informed as possible for starting the sprint planning. To make sure this happens, there are a series of activities which teams can perform alongside the product owner and the stakeholders.
The first of these is to gain clarity on the potential user stories that are being considered for the sprint. The team, together with the product owner will discuss each user story to make sure they understand the scope of the work involved. If this cannot be defined between the team and the product owner, then the stakeholders that requested the work should be called to clear up exactly what they need from the story. Once this has been defined and the team understand what is needed, the team should then scope this story out. One thing that is important at this point is to consider whether the story has the same meaning for all members of the team as there may be a chance that cutural differences between team members may mean that definitions could be slightly different. This all then leads to the team understanding what they have to deliver at the end of the sprint for this particular story and also what acceptance test criteria would be deemed necessary to mark this story as ‘done’. Clarifying the acceptance criteria also highlights whether there are any specialised skills needed to complete this item, this may affect the priority of the story in the product backlog.
Once these stories have been defined, the next task would be to break them down, for a team that knows it’s velocity, they should be able to break them down based on that. This will speed up the actual planning meeting process as many teams would go into this meeting with items too large for their sprint and spend most of the time breaking the items down rather than actually planning the sprint. The key thing here is that if they break these stories down before the planning meeting, they will know earlier exactly how much work they need to do. During the pre-planning, it is important for team members to identify any user stories which they feel are too big for a sprint and then spend some time breaking them down. It is important at this stage not to try to make the stories fit into a sprint, if they don’t fit without manipulation then they are too big and should be split into separate user stories, there will be a risk when trying to squeeze them in that tasks will be forgotten and then there will be additional work to add into future stories.
It is important that when clarifying user stories and breaking them down, the team works to eliminate as many dependencies between stories as physically possible in the product backlog. A good user story is independant of all others stories, obviously there are occasions where this is not 100% possible but doing all that can be done to minimise the dependency is important.
The pre-planning phase is also a good platform for all members of the team to discuss whether the current prioritised backlog actually still works for the release of the product, it is important that any stories that are no longer relevant are either de-prioritised or removed completely. It is paramount that the backlog does not just become a dumping ground for any possible features that may be wanted at some point in the future.
Holding these pre-planning meetings should not become a distraction to the work of the sprint, it should be timeboxed to a manageable amount of time and it should possibly be scoped into the previous sprint. It is important that the team is always looking forward and is aware of what is coming in future sprints so having it planned that in the last week of the sprint, you will have a meeting to flesh out the backlog for the next sprint, means the team will be able to focus towards that.
All this should make the actual sprint planning meeting run more smoothly and everyone in the team should be more aware of what is going to be in the sprint and how they can complete these stories and pass the user acceptance criteria.