A warehouse manager needs to adjust inventory. The system says 150 cases on hand. The actual count is 130. She opens the form, enters the adjustment, and submits.
That’s the happy path. We write a story for it, discuss it in refinement, and start building.
Then someone asks: What if she tries to decrease by more than what’s on hand?
It’s such a simple question. But that question is how edge cases actually get discovered, not by reading requirements documents, but by someone pausing mid-conversation and saying, “wait, could that happen?”
My job is to make sure we pause long enough to ask.
Stories Are Not Requirements
Part of what I’ve learned over many years of working on software is that user stories are not requirements. Nobody goes home and says, “Let me tell you the requirements of my day.” They tell stories.
So when we discuss a story as a team, we’re not reading a spec and checking off boxes. We’re trying to understand the people behind the work. Who is using this feature? What are they trying to accomplish? What does their day look like?
When we understand the story well enough, the edge cases start showing up naturally. They’re not buried in some elaborate spec document. They live in the gap between what the product owner described and what actually happens at the warehouse on a busy Wednesday.
The Question That Opened the Door
We were talking through a “lot adjustment” feature. A team member asked whether we should handle the case where someone tries to decrease inventory by more than what’s currently on hand. A good question. One that might get lost in a requirements-driven process.
That question opened up a conversation, and that’s where the real facilitation work begins.
I’ve found that the most useful thing I can do in that moment is not assume the answer. Instead, I ask.
The Five Questions
Over time, I’ve developed a set of questions I bring into these conversations. They’re not written down anywhere formally, but they’ve become a kind of mental checklist I run through when an edge case surfaces.
Who is affected by this?
Not every edge case touches everyone. Some affect only the warehouse team. Some only matter to accountants at month-end. Knowing who is affected tells me whether this warrants a dedicated solution or is a footnote in the process.
Why does it matter?
Sometimes an edge case matters a lot. Sometimes it’s a one-in-a-thousand scenario that nobody has worried about in years. I want to understand the gravity of the problem before we start designing solutions.
Does it affect revenue or cause a loss?
This is the business value anchor. If the edge case means we can’t fulfill an order, or that we’re writing off product incorrectly, it moves to the top of the list. If it’s a nuisance but doesn’t touch the money, we can be more deliberate about when and how we address it.
When does it happen?
This one is more subtle than it sounds. “When” in the workflow matters as much as “when” on the calendar. For some roles, a problem needs to be flagged the moment it occurs. For accountants, something that happened on a Tuesday may not matter until they’re closing the books two weeks later. The timing tells me which solution is appropriate: a hard stop, a warning, or a deferred notification.
What’s the two-week version?
Once we’ve talked through the edge case and agreed it needs a solution, we often find ourselves drawn toward the ideal answer. The elegant, fully thought-out, perfectly designed solution. And sometimes that solution would take four weeks to build.
So I ask: what would a two-week version look like? Not perfect, but something. Something that addresses the most pressing part of the problem without blocking everything else.
What the Stakeholder Tells You Next
The answers to these five questions tell you more than the question itself.
Sometimes the stakeholder says, “That happens, but it’s rare, and when it does, there’s a separate process for it.” That’s a signal. There’s probably a workaround already in place, something informal, something worth understanding before we automate anything.
Sometimes they say, “That happens all the time. It’s a nightmare. The current system doesn’t handle it well at all.” Now I’m learning something different. Now I know that the legacy system is actively causing pain in a way that wasn’t described in any story. The edge case is actually the main case.
Those two responses call for completely different solutions.
Asking Better Questions Is a Practice
A developer on the team asked a version of this during our session: Do we have a set of standard questions for these conversations? A checklist?
Not exactly. But I told her that as she watches these conversations happen, she’ll start to see the pattern. She’ll notice which questions I ask and why. And she’ll start developing her own version of this instinct.
That’s really the point. Facilitation isn’t a script. It’s a practice. The goal is to ask better questions more consistently, and to recognize when a conversation is moving past a surface-level answer without actually surfacing the problem.
Getting better at that takes time. But it starts with noticing that there’s a question worth asking in the first place.
Leave a Reply