One of the most difficult discussions that occur among Agile practitioners revolves around the need for preplanning and backlog grooming (the good use of the term). Preplanning generally occurs late in a the previous sprint for an upcoming sprint when the team can predict whether everything can be completed
and a few days before the standard sprint planning exercise. I typically aim for the Wednesday before the end of the previous sprint. The preplanning meeting should take no more than an hour for a two-week sprint. The goal of the meeting is two-fold.
First to ensure the backlog is prioritized, and second that the stories that are probably going to be put forward are properly formed (are in the proper format, they make sense, include initial acceptance criteria and include references to any required ancillary materials).
Arguably the most important reason to preplan is to ensure that main sprint planning meeting held with the full core team on the first day of the sprint is efficient, effective and time boxed.
When going into the actual planning meeting, the sprint team needs to have:
- A fully prioritized 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.
If you want to discuss about this topic don’t hesitate to reach me at twitter (@metlucero) or Skype (metlucero)