The IIL Blog

LinkedIn Newsletter | Join our Email List
Pilots Need Flight Planning, Scrum Teams Need Sprint Planning

Pilots Need Flight Planning, Scrum Teams Need Sprint Planning

By Tom Friend, FLEX Coach, CSP, ACP, AHF, PSM, CSM | Business Agility Consultant, IIL

Many years before my career in software development, I was a pilot in the U.S. Air Force, flying aircraft all over the world. As fantastic as this sounds, it did require planning and preparation to ensure that each flight was properly set up for success.

Before every flight, the crew would sit down with a set of data and mission goals, and plan the flight to the best of their ability and knowledge. The measurable successes of each flight mission were directly tied to the quality of the flight crew’s preparation. For every flight, equipment and cargo loads, fuel, crew, weather, and many other variables needed to be taken into consideration during flight planning.

Just as flight planning ensures the success of a military mission, Sprint Planning ensures that a Scrum Team will start a sprint off on the path to success.

For example, all of the work to be performed in a given Sprint can be planned ahead of time. This plan, therefore, sets measurable, actionable goals for the team to strive for. This plan, which is created by the collaborative work of the entire Scrum Team, maps out the plan to the destination. In Scrum, just like in aviation, the destination is the overarching goal. Whether it’s a flight crew or a Scrum Team, a collective plan will set you on the successful path to your end goal.

The Scrum Guide™ mentions some questions which Sprint Planning is designed to address: What can be done in the Sprint? How will the work get done to meet the Sprint Goal? What Product Backlog Items in the Product Backlog are priority and will be considered for the Sprint? In Scrum, the Product Owner stacks the top actionable product backlog items (PBIs) by value at the top of the Product Backlog to help answer these questions.

The destination is usually found in the PBIs selected by the Product Owner. In order to be selected and brought to Sprint planning, the PBIs need to be prepared and refined to a point that they are sized and understood by the team. The number of PBIs is based on capacity of the team over the next sprint.

Once the Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is the destination met through the implementation of the selected PBIs. It provides direction to the Team on why it is building the Product increment, the output of the sprint.

Once the PBIs and Sprint goal are selected, the Team collaborates how to get to a ‘Done’ product increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog. This is the flight plan for the sprint.  Each PBI constitutes a segment in the flight plan of working product increment that gets the team closer to the destination sprint goal.

During the course of Sprint planning, the Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend in order to provide technical or domain advice.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

The similarities between Sprint Planning and flight planning are numerous. With my experience as both an Air Force pilot and as a Scrum Master over the years, I have learned how to build simple checklists which provide a path to the goal, consistency between projects, and better outcomes for individuals, teams, and the Sprint process.

Below is an outline of a Sprint planning checklist, which you may find useful in planning out your sprints. Consider it a starting point to build your own if you have interest. Best of luck!

Sprint Planning Checklist

  1. Scrum Master Open the Sprint iteration meeting
    1.  Welcome
    2. Review purpose
    3. Agenda
    4. Organizing tools
    5. Parking Lot
  2. Product Owner Product Vision and Roadmap; Remind the team of the larger picture
  3. Agile Team Status update group huddle
    1. Development status, state of our architecture, results of previous iterations
    2. Discuss any new information that may impact the plan
  4. Scrum Master Share velocity
  5. Determine the time box and total working days (subtract days for holidays or other whole-team impacting events)
  6. Scrum Master Check in on any currently known issues, concerns, impediments, and record as appropriate to revisit at future meetings
  7. Team Review and update definition of Done
  8. Product Owner Present the Stories from the Backlog
  9. Delivery Team Determine tasks, signs up for work, and estimates tasks they own
    1. Product Owner Answer clarifying questions and elaborates acceptance criteria as appropriate
    2. Scrum Master Facilitate collaboration Key focus
      1. Tasks
      2. Estimates
      3. Owners
  1. Scrum Master Check for new issues after the clarifying questions and records them for appropriate action
  2. Scrum Master Check in on any dependencies or assumptions determined during planning and record as appropriate
  3. Team Commitment to the Product Owner for the Tasks they have accepted
  4. Sprint Name and goal is finalized, can be a collaborative effort
  5. Scrum Master Close the meeting
    1. Communication / Story updates / WIKI / Emails as needed to Capture and communicate lessons learned
    2. Parking Lot – all items should either be determined resolved or turned into Action Items
    3. Action items assigned and agreed on
    4. Process Action Plan – distribute action items to owners
    5. Retrospective for the Meeting Iterative feedback for the meeting itself makes them better for the team and empowers them to take ownership
    6. End on a high note

About the Author

Tom Friend is an Agile Coach and Trainer currently at Duke Energy in Charlotte, NC.  Tom is a retired military pilot, small unit leader, and squadron commander. He is an accomplished Agile consultant, trainer, and coach with 23 years’ experience leading software development teams in various industries to include federal, banking, cable, telecommunications, and energy. He has 12 years of hands on Agile / XP / Scrum software development experience.  He is a distinguished graduate from Air War College and has a BS in Aeronautics.

Scroll to Top