The early bird catches the worm...

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

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.

Sprint planning is a team sport.

Sprint planning is a team sport.

Sprint planning is a collaborative process. It is an Agile team sport.  All members of the core team actively participate in the process with the focal point shifting as the process evolves. Mike Cohn describes planning in Agile like an onion – it has many layers. In the overall flow of an Agile project, the sprint planning comes after release planning and is the first step of a sprint. It precedes the daily meeting, which represents a lower level of planning. The basic flow I use for sprint planning is as follows:

  1. The product owner identifies the units of work he or she would like addressed in the sprint that is just initiating.  The product owner uses the prioritized backlog, the team’s velocity, information gathered through consultation with the team and interaction with other stakeholders.  In most mature Agile teams the process of prioritization and grooming of the backlog (which is central to the planning process) goes on constantly.
  2. Based on the list of work units that the product owner identifies, the team develops or reviews the size of each unit.  I am a proponent of story points or quick and early function points for the sizing process. Both processes help teams drive out ideas and assumptions about the unit of work that may not occur until much later in sprint.
  3. The team should make sure the sum of the size of the units of work makes sense based on the team’s velocity.  Said another way, make sure you are not considering more work than is rational to deliver.  The more comfortable a team (product owner, Scrum Master and the development team) becomes with their capacity, the less this step is needed.
  4. After the reality check, the team then breaks down the units of work into tasks and activities, including rough effort estimates. All of the tasks needed to meet the unit work’s acceptance criteria and to address all of the components of the team’s definition of done should be identified in this process.  The estimation process forces team members to consider how much work is required to complete a task.
  5. The sum of the required effort is used as a feedback tool for the team to gauge whether they can commit to the identified units of work.
  6. Have the team review the capacity of each team member.  This is important if team members are committed on more than one project (bad) or if you allow people to go on vacations (good).
  7. Once the team reaches a consensus on whether the work can be done in the time allotted, the team then publicly commits to doing the work.
  8. Draw a burn-down or burn-up chart for the sprint (both are described in Metrics Minute entries) for tracking, and finally get to work!

Sprint planning is a critical process for the team to develop a common understanding of what will be done during the sprint.  Sprint planning is one layer of planning in the overall continuous, collaborative planning process required for an Agile project.