The Agile mindset demands frequent, if not constant, interaction among its project stakeholders. Perhaps more so with Scrum, than other frameworks. From Daily Scrum activities to Sprint Retrospective events held every one to four weeks, having a formal facilitator or being a facilitative participant adds tremendous value to successful Sprints. So, who facilitates Scrum events and when? The following activities and events highlight Agile’s Scrum dependence on facilitation.

Scrum Facilitation Events

Unlike waterfall mindsets, Scrum Development Teams stick together—theoretically forever. As they move from project to project, each containing multiple Sprints, new stakeholders appear. While the Scrum Product Owner (SPO) remains largely responsible for the relationship between the stakeholders and the Scrum Development Team, the SPO should encourage more direct communications among members, rather than isolating or protecting either group. Next you will find helpful Scrum facilitation event agendas, inputs required, and comments about the facilitation skills required to lead them effectively.

Interviewing and asking questions drives the prioritization of product features, so the Scrum Product Owner remains vigilant about developing optimal questions, sequencing them, and listening for responses. Some of the input contained within an Ordered Product Backlog[1] derives from interviews, rather than formal Scrum facilitation meetings or ceremonies.

Core Scrum Facilitation Skills

Facilitative skills serve the Scrum Master® and Scrum Product Owner® quite well. Among them consider the core skills that include:

Likewise, the entire Scrum Team (including the Scrum Product Owner, Scrum Master, and Scrum Development Team), operates more effectively when using core facilitation skills. Arguably, we all remain more effective embracing a facilitative approach, even in our private lives.

Scrum Facilitation Events and Activities[2]

Scrum Facilitation

Scrum Facilitation

Sprint Zero

Product Release

The launch of a Scrum team depends on need and financing. Typically the incentive derives from building a new product (software, hardware, or service).  Throughout the following Scrum discussion, as the words Product Backlog are used, they could refer to something intangible as well. Additionally, aside from the first letter in sentences, when words are capitalized, it’s because they are capitalized in the Scrum Guide or because they refer to a Tool that is found in our curriculum.

Many refer to a product release project as an epic, a big chunk of work. The epic is broken into multiple themes, or features. Each theme or feature constitutes a number of requirements or stories. Detailed story ‘slices’ may be called user stories or requirements.

The Scrum Guide does not use the terms ‘epic,’ ‘theme,’ ‘feature,’ or ‘story,’ and thus we strive to avoid relying on these terms as well. Since Mike Cohn, Kenneth Rubin, and others have made these or similar terms common parlance, we rely on you to adapt the Scrum framework and on our ‘plain vanilla’ facilitation to guide your terms.

To launch into a series of Sprints, we need to establish the product vision (or goal) and some of the objectives and reasons associated with justifying the investment.  The following can help establish a baseline for moving forward.

Project charters could like anything from over thirty pages to a Six Sigma® charter that is required to fit on a single page. We remain methodologically agnostic, but suggest that all versions have one thing in common, a statement of purpose.

Purpose of the Organization

First we need to understand the reason for the existence of the sponsoring group, the customer or primary stakeholder. While components like mission, values, measures, etc., are typically found, you can also substitute our Purpose Tool to build a quick and consensual understanding of the general context for the product.

Purpose of the Product

Next, at a minimum, we need to establish the purpose of the product (frequently referred to as a project). Again, while teams will normally develop an opportunity statement, situation analysis, etc., we can roll up the primary reasons for the prupose of the Product with the Purpose Tool. Once we have both, there should be enough information to move ahead with a series of Sprints to develop the product.

In addition to frequent one-on-one and one-on-few sessions, along with ongoing Backlog Refinement, the Scrum framework requires four formal Scrum facilitation events for inspection and adaptation during each Sprint. They include:

  1. Sprint Planning
  2. Daily Scrum
  • Development work (including Product Backlog Refinement; technically an activity, not an event—typically more than one Refinement activity per Sprint)
  1. Sprint Review
  2. Sprint Retrospective

As a coach, impediment remover, and generally serving as a neutral party, the Scrum Master remains best suited for facilitating Sprint Planning and Sprint Reviews.  Occasionally, an outside Scrum Master facilitates the Sprint Retrospective so that the participating Scrum Master may contribute as a participant.

Suggested Scrum Event Durations per Sprint (maximum)

Based on a maximum four-week Sprint, the table shows the maximum allocated time for each Scrum facilitation event or activity:

Sprint Duration/

Event Type

Four Weeks

Three Weeks

Two Weeks

One Week

Sprint Planning

Eight Hours Six Hours Four Hours Two Hours

Sprint Review

Four Hours Three Hours Two Hours One Hour

Sprint Retrospective

3.0 Hours 2.25 Hours 1.5 Hours 0.75 Hours

Product Backlog Refinement
(typically more than one session)

Ten percent of the Sprint duration. (e.g., 4wk Sprint = 16hr Refinement) Ten percent of the Sprint duration. (e.g., 3wk Sprint = 12hr Refinement) Ten percent of the Sprint duration. (e.g., 2wk Sprint = 8hr Refinement) Ten percent of the Sprint duration. (e.g., 1wk Sprint = 4hr Refinement)

One can quickly see that a Scrum Master should project up to eight hours of Scrum facilitation per week. Allowing a standard ratio of 2:1 for thorough preparation, a Scrum Master could be directly involved in Scrum facilitation sixty percent of their time.

While many Scrum Certification programs explain the event details, few provide extra training on the facilitation skills required. While many, if not most, of our blogs provide insight on the servant skills of facilitators, our face-to-face training yields greater insight. Next you will find helpful Scrum facilitation event agendas, inputs required, and comments about the facilitation skills required to lead them effectively.

SPRINT PLANNING

Overview

The entire Scrum Team takes on Sprint Planning to determine WHAT can get done over the next Sprint and HOW they will do it (high-level). The table that follows covers inputs, potential tools, and brief comments about each step focused on servant leadership (facilitating).

Timing

Strictly time-boxed to eight hours duration for a four-week sprint and sized down according to the length of shorter sprints.

Purpose

The purpose is to identify WHAT will get done over the next Sprint and approximation about HOW (high-level tasking) it will be completed.

Specifically, Sprint Planning answers the following: 

  • What can be delivered in the Increment resulting from the upcoming Sprint? 
  • How will the work needed to deliver the Increment be achieved? 

Primary Inputs

Some of the information that should be brought in or visually displayed include:

  • Product Backlog items (ordered by Product Owner)[3]
  • Pre-identified potentially shippable product Increment (PSPI)[4]
  • Development Team capacity (during the Sprint)
  • Metrics, especially velocity 
  • Identified Sprint Retrospective action (Kaizen)
  • Draft of Sprint goal from prior Sprint Review and current Sprint goal of the Product Owner

Deliverable

The Sprint Goal and the Sprint Backlog that upon customer acceptance will yield the Sprint Increment, updated Product Backlog with Kaizen. Optionally, an updated Product Vision and Scope.

Method

Next, see the Sprint Planning Agenda table that includes specific inputs for each step, tool options for facilitators, and additional comments related to the facilitation of the event.

Sprint Planning Agenda Step
(also describes step output)

Inputs Required

Tool Options
and Comments

Launch

  • Meeting purpose, scope, deliverables, and simple agenda
  • Ground rules and optional ice breaker if team building
  • Product and/ or release scope and vision (goal)
  • Use the standard MG RUSH seven-activity introduction.
  • Anticipate verification or alignment with product goal or vision, technical road map, and release plan (as available)
  • NOTE: Scope covers the next Sprint only

Potential Sprint Goal

  • Draft Sprint Goal from the Sprint Review
  • Product Owner updated Sprint Goal
  • PSPI (potentially shippable product Increment)
  • Product Owner ordered (prioritized) Product Backlog
  • Have the Product Owner review their Sprint Goal
  • Have the Product Owner review their updated and ordered Product Backlog
  • Facilitate refinement (if necessary) using supplemental tools:

Product Backlog Sizing
(Relative Estimating)

  • Confirmed or updated ordered (prioritized)
    Product Backlog (from Sprint Goal step above)
  • Kaizen highlighted (Sprint Retrospective action item)
  • Frequently estimated using prior velocity and Fibonacci scoring scale
    (i.e., Planning Poker or Affinity Sizing)
  • Might also add prior Sprint Retrospective action item (Kaizen)
  • Facilitate refinement (if necessary) using supplemental tools:

Sprint Capacity Planning

  • Prior Sprints’ metrics on velocity (e.g., burn-down and burn-up charts)
  • Interrupt buffer (capacity constraints)
  • Considers capacity constraints due to illness, PTO (paid time off), etc.[5]  
  • Calculation formula
  • Facilitate refinement (if necessary) using supplemental tools:

Sprint Backlog Selection

  • Sized (estimated) Product Backlog (from Sizing step above)
  • Capacity (from Capacity step above)
  • Potential Sprint Goal (from Goal step above)
  • Dependencies (other Product Backlog items)
  • Facilitate refinement (if necessary) using supplemental tools:
  • When customer approved will result in a Sprint Increment (potentially shippable product Increment, or PSPI)

Sprint Backlog Tasking

  • Ordered (prioritized) and estimated Sprint Backlog (from Selection step above)
  • Kaizen highlighted (Sprint Retrospective action item)
  • Ensures optimal level of resolution for subsequent Development Team discussions and additional “slicing” (understanding that much of the technical design occurs after the Sprint Planning session)
  • No task should exceed one-day or eight hours labor effort
  • Maybe helpful to consider a Roles and Responsibilities (RASI) tool.
  • Facilitate refinement (if necessary) using supplemental tools:

Final Sprint Goal

  • Sprint Backlog (from Selection and Tasking steps above)
  • Draft Sprint Goal and release vision (from Goal step above)
  • Story acceptance criteria of DONE (from Tasking step above)
  • Finalized, understood, and supported Sprint Goal statement
  • Align with WHAT will get done (selection or Sprint Backlog) to confirm final acceptance by Development Team
  • May consider using supplemental tools:

Review and Wrap

  • All output from above steps but primarily the finally selected Sprint Backlog and potential Increment
  • Parking Lot
    (open issues)

PRINCIPLES OF A DAILY SCRUM

Overview

There are good meetings and there are long meetings but there are not many good, long meetings. The Scrum framework encourages the Development Team to conduct a Daily Scrum (frequently a stand-up meeting). Other stakeholders (in addition to the Scrum Master, Product Owner, and Development Team), may observe and occasionally, the Scrum Master may be invited in as a facilitator.

Timing

Strictly time-boxed to fifteen minutes duration, the Daily Scrum may also be referred to as a roll-call (usually morning) or a daily huddle. To amplify team cadence, conduct the Daily Scrum in the same place and time everyday.

Purpose

The purpose is to allow for inspection and adaptation that will help synchronize the Development Team’s plan and activities over the next 24 hours as well as to identify any impediments for which the team requires outside support.

“Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.” 

Primary Inputs

Some of the information that should be available or visually displayed include:

  • Sprint Goal
  • Sprint Backlog
  • Burn-down chart
  • Impediment list

Three Questions

Daily Scrums provide team members insight about where each Development Team member focuses their activities.  

“The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box. The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.”  

Using the trivium format of yesterday, today, tomorrow, modify the precise questions to meet your needs as follows.

Classic Three

1. What did I do yesterday that helped the Development Team meet the Sprint Goal? (or, What did I accomplish yesterday)?

2. Next, what will I do today to help the Development Team meet the Sprint Goal? (or, What will I accomplish today)?

3. Finally, what impediments prevent me or the Development Team from meeting the Sprint Goal? (or, What obstacles are impeding my ability to get done)?

Motivational Version

1. What you did to change the world yesterday?
(or, What did you accomplish since the last Daily Scrum)?

2. How you are going to crush it today?
(or, What are you working on until the next Daily Scrum)?

3. How you are going to blast through any obstacles unfortunate enough to be standing in your way?
(or, What’s getting in your way, keeping you from doing your job)?

Outputs

  • Socialized plans for the next 24 hours
  • Impediments identified

Comments

The approach of reporting on Yesterday > Today > Obstacles prevents scope creep. Standing, rather than sitting, ensures that meetings remain brief and discourages wasted time.

The Daily Scrum does not provide the time and place to solve problems. Rather, the Daily Scrum approach makes the team aware of its current status. If further discussion is needed, a longer meeting with appropriate parties can be arranged or conducted after the Daily Scrum with only the necessary participants. Topics that require additional discussion should always be deferred until every team member has reported.

Remember to have members focus on WHAT they are doing. Discussions about WHY they are doing it should be deferred to a planning meeting. Discussions about HOW they are doing it should be deferred to a design meeting or technical discussion.

Take the MG RUSH Professional Certified Structured Facilitation class to learn what to say to explain the difference.

PRODUCT BACKLOG REFINEMENT(S)

Overview

Product Backlog refinement occurs as necessary and helps fortify the product Increment expected over the concurrent Sprint. The Scrum Development team meets independently. Others may observe or be invited for input. The Scrum Master stands alert to help remove identified impediments. On occasion, they may be asked to facilitate.

Deliverable

Updated Sprint Backlog and story tasking, along with potential impediments to be noted.

Considerations

Product Backlog Refinement Considerations

Comments

Historical Velocity

Considers effectiveness in burn-down charts or other capacity and estimating metrics. Potentially takes in to account relative scoring or estimation technique for assessing Sprint Backlog item complexity.

Existing Sprint Backlog

Typically focuses on PSPI or the potentially shippable product Increments. Frequently displayed in the format of a Kanban, optimally allows for Product Owner input, explanation, and rationale.

Updated Sprint Backlog

Consensually agreed upon, both sizing (scale) and sequence (ordering) of stories and story slices.  Confirms understanding about “DONE” for each Sprint Backlog item and the method or terms of acceptance criteria.

Burn-up Chart

Method for quickly testing direction for validity and sanity of completing the concurrent Sprint.

 

Kanban Illustration

Kanban Illustration

 

SPRINT REVIEW

Overview

The Sprint Review serves to provide an inspection and adaptation checkpoint for the Product development (e.g., multiple Sprints) and includes the Scrum Team and stakeholders. Because stakeholders attend, consider a dry-run rehearsal before the formal session begins.

Timing

Strictly time-boxed to four hours duration for a four-week sprint and sized down according to the length of shorter sprints. 

Purpose

The purpose is to inspect and adapt the potentially shippable product Increment built over the prior Sprint.

Primary Inputs

Some of the information that should be brought in or visually displayed include:

  • Potentially shippable product Increments (PSPI)
  • Ordered Sprint Product Backlog
  • Metrics such as Velocity and Burn Down chart
  • Sprint Goal
  • Release plan including product and/ or release scope and vision (goal) and technical road map (as applicable)

Deliverable

An updated Product Backlog (and optionally updated Product scope and vision).

Method

The next table shows you HOW TO facilitate a Sprint Review. Keep in mind there is more than one right answer, and more than one right tool per step.

However, there is a wrong answer too.  That is, if you don’t know how you are going to facilitate the session before it begins. Make sure as the meeting leader, you know what “DONE” looks like.

Sprint Review Agenda Step
(also describes step output)

Inputs Required

Tool Options
and Comments

Launch

  • Meeting purpose, scope, deliverables, and simple agenda
  • Ground rules and optional ice breaker if team building
  • Product and/ or release scope and vision (goal)

Sprint Goal Reflection
(Results)

  • Milestones (Significant point in development such as percentage complete, releases, epic, etc.)
  • Product vision (scope, objectives, deliverables)
  • Ordered Product Backlog
  • Technical road map
  • Release plan
  • Potentially shippable product Increment — PSPI (just built)
  • Metrics — (commit vs. delivered)
  • Velocity
  • Product Owner conducts a thorough, yet natural walk-down from product vision, technical road map, release plan and then summarize the Sprint Goal and potentially shippable product Increment (being delivered)
  • Scrum Master can facilitate and conclude this agenda step using the tool called the Three Question Approach:
    • What (if anything) do we need to clarify ?
    • Next, what (if anything) do we need to delete ?
    • Finally, what (if anything) do we need to add ?

Sprint Reflection – Demonstration
(for 
EACH Theme,
or Story)

  • Potentially shippable product Increment — PSPI (just built)
  • Kaizen highlighted (Sprint Retrospective action item)
  • Consider having the customer use each new product Increment (e.g., operate the mouse) while the Development Team provides a voice over.  See method for each product Increment (e.g., theme or story)as follows below.
  • Alternatively, the Development Team demonstrates (e.g., works the mouse and the screens) the PSPI (potentially shippable product Increment) and the Product Owner provides a voice over.
  • The Scrum Master modifies the Content Management tool as shown in the next three agenda steps.

DONE
(Facts)

  • One completed (“DONE”) story Increment at a time, completed demonstration for EACH story Increment
  • WHAT:  Verification of clearly understood product Increment, or clarification of issues that require further explanation.

Acceptance
(Implications)

  • Clearly understood product Increment
  • Stop Light (Customer approval – Yes, No, Conditional Acceptance)
  • SO WHAT: Clear documentation of the rationale to accept or need for further  understanding on anything rejected or accepted conditionally.
  • Be prepared to use the Definition Tool to help clarify misunderstandings

Revision
(Recommendations)

  • Understood reasons for rejecting or modifying the previous Increment
  • All Increment demonstrations completed
  • NOW WHAT:  Potentially update the Product Backlog to everyone’s general satisfaction, including voice of the Product Owner and Development Team (especially documenting their reasons).

What’s Next

  • Reverse walking up the ladder, back to product vision
  • Previous ordering (prioritization)
  • Draft of an updated Product Backlog
  • Milestones
  • All product and release vision material
  • Product Owner conducts a thorough, yet natural walk-up from newly drafted Goal for the next Sprint to modified Product Backlog to release plan to technical road map to product vision.
  • Scrum Master can facilitate and conclude this agenda step using the Three Question Approach:
    • What (if anything) do we need to clarify ?
    • Next, what (if anything) do we need to delete ?
    • Finally, what (if anything) do we need to add ?
  • Facilitate refinement (if necessary) using supplemental tools:
  • Results in updated Sprint Backlog for the Scrum Team to consider during its Sprint Retrospective and next Sprint Planning sessions.

Review and Wrap

  • All output from above steps but primarily the confirmed acceptance Increments and or rejected/ modified Increments
  • Parking Lot (open issues)

Scrum Team Tools

Some other tools that a Scrum Team might consider based on the suggestions and lead of the Scrum Master include:

SPRINT RETROSPECTIVE

Overview

Here the Scrum Team inspects and adapts to impediments.  

Arguably the most important meeting of all, intended to ensure continuous improvement, experts recommend three hours of preparation for a ninety-minute Sprint Retrospective.

Planning Sprint Retrospective activities helps the team get better while preventing boredom. Thoroughly prepared activities lead to stronger results.

Timing

Strictly time-boxed to three hours duration for a four-week sprint and sized downward according to the length of shorter sprints.

Purpose

The purpose is to inspect and adapt the team’s efforts and results over the prior Sprint.

Primary Inputs

Some of the information that should be brought in or visually displayed include:

  • Last Sprint Retrospective action
  • Metrics (especially burn-up and burn-down velocities)
  • Definition of DONE (for each Increment or theme)
  • Process standards and practices (i.e., internal framework)
  • Impediment list

Deliverable

An improvement plan with an identified focus on one thing to do better over the next Sprint (Kaizen).

Method

The next table shows you HOW TO facilitate a Sprint Retrospective. Keep in mind there is more than one right answer, and more than one right tool per step.

However, there is a wrong answer too. That is, if you don’t know how you are going to facilitate the session before it begins. Make sure as the meeting leader, you know what “DONE” looks like.

Sprint Retrospective Agenda Step
(also describes step output)

Inputs Required

Tool Options
and Comments

Launch

  • Meeting purpose, scope, deliverables, and simple agenda
  • Ground rules and optional ice breaker if team building
  • Product and/ or release scope and vision (goal)

Facts (Learnings)
aka “
WHAT

  • Sprint Review meeting notes (results)
  • Impediment list (especially the previous Sprint Retrospective impediment)
  • Product Backlog
  • Burn-down chart and other velocity and capacity metrics
  • Other standards, practices, etc.
    (internal framework)
  • Strive to prevent boredom with varying and creative means to capture WHAT impediments were observed.
  • Provide detailed questions, that help identify specific personality dynamics, process challenges, equipment problems, or any other impediments.
  • Might require an outside Scrum Master if the Sprint Team’s Scrum Master needs to make substantive content contributions or participate in content discussions.

Insight

aka “SO WHAT

  • Facts and impediments (from Learnings step above)
  • Kaizen highlighted (prior Sprint Retrospectives)
  • Product Backlog
  • Draft Sprint Goal (from Sprint Review)
  • Various metrics

Kaizen (Improvements)

aka “NOW WHAT

  • Implications (from above Insight step)
  • Product Backlog
  • Draft Sprint Goal (from Sprint Review)
  • Various metrics
  • Help the team embrace some adaptive ideas based on the implications identified in the previous step.
  • Isolate and focus on “one thing to do better” over the next Sprint. Consider:

Review and Wrap

  • All output from above steps but primarily the confirmed Kaizen or impediment improvement item
  • Parking Lot (open issues)

Comments

Each step involves potentially multiple team activities and innumerable, creative tools such as:

  1. Amazon Review
  2. Five Why’s or quick RCA (Root Cause Analysis)
  3. Lean Coffee
  4. Mad/ Glad/ Sad (Stop/ Start/ Continue)
  5. Participant Prioritization (using various tools over the life-cycle of the project)
  6. Post-it Note Affinity Diagram
  7. Remember the Future (Temporal Shift)
  8. Starfish
  9. Speedboat/ Sailboat
  10. Three Words

Finally, please remember that the voting method (e.g., ‘dots’) of prioritization does not generate higher quality decisions, only a bigger number. Consider some the various tools offered by MG RUSH for both prioritizing and conducting many of the identification activities required during your Sprint Retrospective.

Scrum Facilitation in Conclusion

Finally, please remember that the Voting Method of prioritization does not generate higher quality decisions, only a bigger number. Consider some the optional tools offered by MG RUSH as solid alternatives for both prioritizing and conducting many of the activities found during your Scrum Sprints.

______

[1] The Scrum Guide was modified in 2011. The Product Backlog became “ordered,” instead of “prioritized,” providing flexibility to the Product Owner to optimize value in his or her unique circumstances.

[2] ©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons. 

[3] Depending on the level of resolution or specificity, itesm could be broad (epic), moderate (theme), narrow (story), or ready (story slice)

[4] An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

[5] PTO reflects Paid Time Off or other planned or surprise reasons for absences.

______

Finally, MG RUSH professional facilitation curriculum focuses on providing methodology. Each student thoroughly practices methodology and tools before class concludes. Some call this immersion. We call it the road to building impactful facilitation skills.

Become Part of the Solution While You Improve Your Facilitation, Leadership, and Methodology Skills

Take a class or forward this to someone who should. MG RUSH Professional Facilitation Training provides an excellent way to earn up to 40 SEUs from the Scrum Alliance, 40 PDUs from PMI, 40 CDUs from IIBA, and 3.2 CEUs. As a member of the International Association of Facilitators (IAF), our Professional Facilitation Training aligns with IAF Certification Principles and fully prepares alumni for their Certified Professional Facilitator designation.

Furthermore, our Professional Facilitation curriculum immerses students in the responsibilities and dynamics of an effective facilitator and methodologist. Because nobody is smarter than everybody, attend an MG RUSH Professional Facilitation, Leadership, and Methodology workshop offered around the world, see MG RUSH for a current schedule.

Go to the Facilitation Training Store to access our in-house resources. You will discover numerous annotated agendas, break timers, and templates. Finally, take a few seconds to buy us a cup of coffee and please SHARE.

In conclusion, we dare you to embrace the will, wisdom, and activities that amplify a facilitative leader.

Facilitation Expert

Terrence Metz, CSM, CSPF, is the Managing Director of MG RUSH Facilitation Training and Coaching, the acknowledged leader in structured facilitation training. His FAST Monthly Facilitation blog features over 300 articles on facilitation skills and tools aimed at helping others lead faster, more productive meetings and workshops that yield higher quality decisions. His clients include Agilists, Scrum teams, program and project managers, senior officers, and the business analyst community among numerous private and public companies and global corporations. As an undergraduate of Northwestern University (Evanston, IL) and MBA graduate from NWU’s Kellogg School of Management, his professional experience has focused on process improvement and product development. He continually aspires to make it easier for others to succeed.

Visit Our Website

2 Comments

  1. Great article! I love the idea of using what, so what, now what for retrospectives. Often teams use this event for complaining without any analysis of the actual issues. This tool will help take some of the drama out.

    • Thanks for taking your valuable time to provide a comment Denise.

      Groups cannot focus on more than one thing at a time and yet each of the symptoms, causes, and cures implies a potential “one to many” arrangement. Some structure goes a long way to normalize those challenges.

      As consultants we used polysyllabic terms in the past; namely Evidence (symptom) yielding to Implications (causes) leading to Recommendations (cures or actions). We’ve learned that the grandparent friendly terms of WHAT > SO WHAT > NOW WHAT effectively explain the structure and make it easier for groups to follow and stay focused.

      More importantly, the facilitator can measure what is ‘Done’ and more importantly, what is NOT ‘Done’. And you know Denise, once you can measure it, you can manage it.

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.