Having common goals and definitions helps to lift the fog.

Having common goals and definitions helps to lift the fog.

The first two articles on sprint planning have sparked a number of interesting side conversations about logistics and precursor concepts.  There are several constraints, concepts and ideas that the team needs to keep in mind to facilitate effective sprint planning. For good planning, all teams must understand the goal of the sprint they are planning, the definition of done and the time box for completing planning. 

The sprint goal (or goals) is the high-level business and technical target for the sprint.  The goal acts as an anchor that roots the units of work that product owner will ask the team to complete in the upcoming sprint.  The sprint goal is a touch point that each team member can use to make the moment-to-moment decisions every development team makes. The goal can also be used as a communication vehicle to help stakeholders and others outside the team understand what will be delivered during the sprint.

The second concept all teams must understand prior to beginning sprint planning is the definition of done. The definition of done represents both the team’s and organization’s expectations of the state of the functional software when the sprint is complete. For example my standard definition of done is:

  • Design documents developed (if needed)
  • Code written
  • Required code comments written
  • Unit tests preformed
  • Integration test executed
  • Release notes developed
  • Acceptance criteria met

The unit of work is not done until all of these criteria are complete.  Every organization will have its own list of macro tasks that are required to show demonstrable value.  For instance, my base list includes design documents. Several of my clients are contractually required to produce design documents.  Without the design (or with an incorrect design document), they will not be able to deliver the software and get paid.

Third, the whole team needs to understand the planning time box.  As a general rule, the preplanning meeting should last no more than an hour for a two week iteration (30 minutes for a one week iteration).  The main planning session should be planned to last no more than two hours for each week of sprint duration.  The time box helps teams stay focused (also keeps me from telling stories), and from being overly precise (which usually represents false precision), which can cause the team to spin into planning paralysis. When the clock strikes the planning time box is over and the team needs to start executing.  The plan will be revisited during the daily meeting.

Teams need to begin planning with a firm grasp of sprint goal to provide direction and focus.  Explicitly understanding the expectations for what done means will help the team plan activities and tasks.  The definition of done also helps the team keep each other on track because they all have common expectations.  Finally, planning like most team sports, is constrained by a clock.  The time box keeps the team from spending the entire sprint planning rather than delivering.