So the answer is . . .

A minor update for Sprint Planning in late 2019!  At some point planning for planning needs to give way to planning.  Planning identifies a goal and helps to envision the steps needed to attain that goal. In Agile, the planning event also sends a message about the amount of work a team anticipates delivering in an iteration. While every team faces variations based on context and the work that is in front of them, a basic planning process is encapsulated in the following simple checklist.

Planning Preamble:  

As the team gets settled and before they leap into breaking work down into smaller stories, activities, and tasks the facilitator (e.g. Scrum Master in Scrum) should remind the team of the basics of planning, the ground rules, and expected outcome. The basics include:

___  How long the planning session will last (everything is time-boxed)

___  The time frame the team is planning for (e,g, a day, two weeks or several iterations).s

___  Everybody writes and everybody needs to participate.  

Not using a scribe tends to keep people involved. Also having everyone involved in the recording will help ensure that the records are not the sole responsibility of a single person which is a potential future constraint.

___ Gather your numbers

Each team should understand their through-put (how many work items typically completed in a sprint) and shocks to capacity (are any team members not going to be available more than normal during the iteration)

___ Decide on the planning order.

Planning order is often addressed in grooming, by organizational and/or team culture, or upfront as part of the chartering. Review the order and the rationale for it.  The three most prevalent ordering strategies are:

  1. Hardest Part First
  2. Highest Value First
  3. Dependency Driven (those that can’t be avoided)

___ Definition of Done

Everyone in the planning should agree on what the base components of done mean and whether anything out of the ordinary needs to be kept in mind during planning.  Remind everyone that done is not the same as acceptance criteria.

Business Context:

Providing business context is similar to reviewing the basics.  Business context serves many purposes, including motivation and answering the question of “why?” for the team.  The business context will help the team to make decisions more effectively and efficiently. Business context items include:

___ Iteration Theme.  

The theme defines the overall goal.

___ Business Constraints

Are there business constraints that should be accounted for during planning?  For example, sometimes functionality is needed on a specific date due to legal mandates or other events.  One client had to plan to deliver a prototype for an industry show.

___ Important Discussion From Grooming

Grooming, like any business conversation, is a data-gathering event.  Always share relevant information with the whole team.  


Planning is a process of decomposing work into smaller pieces.  Teams begin with groomed user stories and then break them into tasks.  Breaking the work down allows team members to gain a better understanding of what needs to be done and how much work can be accomplished during the iteration.  Breaking work down also allows the work to be spread across the team based on capabilities and so that the team can swarm to the work when there are issues. Considerations and guidelines include:

___ Take the first cut by breaking stories into big tasks before getting into the details.

This step helps teams not to get frozen into planning paralysis and into specifying the solution early in the process.

___ Target a consistent level of granularity for tasks.  

I recommend all tasks be slightly less than a day’s effort which makes it easy to show progress or to identify roadblocks quickly.

___ Plan out loud.

Planning out loud helps to keep everyone involved, away from silo thinking, and makes sure planning stays reasonable.

___ Plan slightly overcapacity.

The team should plan a bit more than their productivity or velocity indicates.  The over plan represents a stretch goal and allows the team to be positioned to continue moving forward if progress is faster than anticipated.  Use your average throughput number to determine a starting point for capacity and then adjust for risk.

___ Remember to set aside capacity for maintenance and support (if needed)

The “if needed” are for teams that have maintenance and support that appear randomly and not be converted to stories and planned normally.

Wrap Up:

Running out of time is not a great way to end a planning session.  Two normal steps help to provide the team with planning closure

___ Review and commit to the plan.

The team should be able to agree that they will accomplish the plan based on the planning exercise.  I suggest testing commitment as planning progresses. However if the team can not commit to the plan, the issue will need to be identified and another planning session convened to address the problem. Note: if the facilitator is testing commitment during the session, this should be a rare event.  When a team will not commit I generally find they have been forced to over-commit by an external party in the past.

___ Do a retrospective

As a team, identify one thing you can do better and commit to making the fix!

The simple planning session checklist is useful to get a team ready to plan, keep the team on track and to improve the process. I have used the checklist as a training tool and as a tool to help guide new facilitators.