Sprint Planning: Preplanning Anyone?

The early bird catches the worm…

One of the more difficult discussions that occurs 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 is that the stories that are probably going to be put forward are properly formed (i.e.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.  An example of a calendar from a two week sprint showing the timing of preplanning and other standard meetings is shown below:

Two Week Sprint Planning Calendar

Participants:  Preplanning generally does not involve everyone on the team.  I suggest a sub-team of three: the product owner, the business analyst and testers.  One reason to constrain the attendance is that people are busier later in a sprint, regardless any discussions on sustainable pace.

Process: As a team, review any units of work that you don’t anticipate finishing.  There is a natural tendency to assume that an uncompleted story will just roll to the next sprint. Do not make that assumption! The product owner should evaluate whether enough has been completed or something new has been learned to change the value proposition on the unit of work.  Re-prioritize the backlog based on what the team and organization knows today (versus what you knew in the last review of the backlog).  The pre-planning team should then walk through the backlog items that are probably going to be accepted into the next sprint plus a few more (always be prepared).  I use the following criteria:

1. Do we understand what the story means?
2. Can the unit of work be concisely explained?
3. Is it small enough to be completed in the upcoming sprint being planned (this is code for: should the unit of work be broken down so that it can flow through the process well)?
4. Is the story formatted correctly? (I am a bit compulsive on format as it reflects mental discipline.)
5. Does the unit of work have defined acceptance criteria?

Stories that fail any of these criteria need to be fixed immediately. That is why the three roles noted above are central to the planning process. The product owner provides his or her understanding of the business need, the business analyst can talk both technical and business languages and the testers know how to prove that the story is complete.  I have seen scenarios where a story can’t be fixed in a timely manner because the preplanning team did not understand the unit of work.  This leads to the unit of work being dropped from the next sprint or addressed as a special research project (known as spike) so that it can be planned in the future.

I once called the preplanning process a pre-chew after watching a special on birds and their child-rearing habits. I used the analogy to make an impression on a group I was coaching, specifically that the preplanning session makes the overall sprint planning process easier to digest.  Preplanning helps to avoid scenarios where the whole team stumbles around trying to decide (or worse arguing) what a unit of work means and what they might have to do to be complete.

Note:  I have friends that recently told me that the preplanning meeting might be in process of being added to the basic Scrum process.  I have no clue whether this is true, but in my estimation it would make a lot of sense.