NDD Facilitation Play-by-Play

This document provides a play-by-play of the facilitation process from the point-of-view of the facilitator. By reading this document, you gain a first-person perspective of what it is like to be a facilitator.   

Today we’re discovering a simple feature. 

A user opens up an application to check their account balance. 

I’ve brought the team together, everyone is keen to start.

Starting the Session

I start by asking the most fundamental question: What business value does this narrative provide? When asking this question, I’m looking for a simple description of the business value. 

A member of the team suggests this outcome: “The user checks their account balance.” Simple enough. I make a note of that by labeling the entire narrative after that outcome.

I notice that this narrative might be part of something larger. 

I ask the team: “Is this a standalone narrative or do you think there will be other related narratives? What are we talking about here in broad terms?”

The team mentions several terms, but one is often repeated and strikes me as relevant: Account Dashboard. I make a note of that concept, as that’s what we call a Capability. Other narratives are sure to stem from it.

‍

The team seems to agree on that label being accurate for the capability. I now take the team back to our narrative. 

I ask: “What’s the defining moment that enables this outcome?” 

The team is quick to respond to this seemingly trivial question. “The user sees the balance on the dashboard,” they say. We have our first moment: “User sees balance.” 

I put that down on the context lane.

‍

But the team gives us more than just that. I have to unpack in real-time what the team conveys by “The user sees the balance on the dashboard.” We already noted the moment “sees balance.” “On the dashboard” – an interface. 

I was not planning to start speaking about interfaces yet, but no plan survives the first encounter with reality. 

I note that down, I put “Dashboard screen” in the interaction lane. I also notice this “User” being mentioned – our Actor. 

I ask: Who’s this “user”? I ask that because I need the team to personify our narratives. “Is the user a consumer? An admin? An auditor?” I’m not fishing for a real name here, but the team seems keen on calling the user “Sally.” I roll with that.

‍

It might not look like much now, but it is. What I have there is one focus point. The team is now outcome-focused. 

I’m now ready to take the team to the beginning part of our narrative. I ask the team “What’s the first step that’ll take us there?” 

After an initial flurry of suggestions, we hear: “From another part of the app,” “They open the app,” “They got a notification,” and so on. All true, all important. 

I note all of them now, some seem to reference other capabilities, and we add those too. But as the facilitators we must keep the team on track. 

I therefore pick the simplest one for this purpose: “They open the app.” That’s our first moment.

‍

I read aloud what we have: “Sally opens the app, sees the account on the dashboard.” Does that sound right?”

The team is not convinced; we see frowns, grimaces, eye rolls. Another flurry of input from the team: “There’s a loading screen, we need that,” “We check credentials,” “It depends if Sally is logged in,” “We check for the app version” among others. 

All true, all valuable input.I now help the team try and figure out what-is-what. Seems like there are quite a few checks we need to do. It’s a key moment, so I note it down.

‍

Sally will see the loading screen while she waits. That’s a new interface.

Several team members, especially technical and from the backend side, give a lot of detail about how those checks work. Somebody asked a question because they didn’t realize checks worked that way. The team realizes they’re not important for this outcome and by not dismissing them the team feels like they have a voice and are encouraged to collaborate. This participation is critical, as I don’t want to shut the collaboration down. To keep conversation on track, and capture these important points being made, I simply note down the highest-level business function of those checks. 

The team reluctantly settles for a generic “Startup checks.” It’s a compromise, but we place a label on this for follow-up and reassure the technical folks we’ll get back to those in greater detail later. We have our first system action.

“Ah but if they fail they take you to the login screen,” “What if there’s no internet? They see an error.” Technical people are trained to think of edge cases, and that’s what we need! 

I note all of that down, they are side narratives and I will need to bring the team together for again so we can come back to those later. 

I don’t want us to forget the focus of our current narrative, its outcome. I help the team stay focused on that objective by bringing them back to the path of success. 

I ask: “What’s the happy path after the checks?” 

They pass – the team agrees. That’s our moment.

I go over the narrative again, aloud. As I read it, I ask: “Does it make sense?” 

I focus on asking if anything is missing. One team member points at the fact that the dashboard needs to get the data from the system. Excellent point. 

I add a new action: “Fetch dashboard.” We connect that action to the “dashboard screen.”

I read the whole narrative once again. I ask the team: “Is this the whole story?” 

The team seems to agree it is. We have our happy path narrative. That’s great! 

Now it’s time to focus on all those side narratives we noted down earlier. I do that using exactly the same process as we did for the main narrative. 

It’s a recursive process and it stops when there are no more narratives to consider. By having all of the narratives in one location I have a single source of truth and then the team will be ready to begin the process of detailing the technical requirements and interface designs.