DEV Community: Tomi P.

Grounded vs. Guessed: A Real Test of AI Agent Context

Tomi P. — Tue, 08 Sep 2026 11:47:06 +0000

I've started running a small, ongoing experiment on myself: how do I actually improve the quality of my own work, and more specifically, how do I hand an AI agent the kind of product context that makes it build the right thing instead of a confident guess dressed up as a spec. This piece is the first real result of that.

I want to show you something instead of just claiming it. So here's an actual experiment, run once, with the real output pasted in, not paraphrased or cleaned up after the fact.

The claim I keep making about story maps and AI coding agents is that a map gives an agent something a chat transcript can't: persistent, structured context. That's easy to say and hard to prove without just showing the receipts. So I ran the same feature request through the same agent twice, once blind, once with real tool access to a real map, and wrote down what actually came out both times.

The setup

One ticket:

"Add a gift wrapping option to checkout. Users should be able to opt to have their order gift wrapped before it ships."

Same underlying model both times. I want to be upfront about that, because it'd be more dramatic to say "two competing AI products" and it wouldn't be true. The variable isn't which vendor's model you use, it's whether that model can read a real, persistent source of context before it answers, or whether all it has is the words in the prompt. That's the actual thing worth testing, and it's the thing that changes regardless of which model you're running.

The map already existed before this experiment started: a checkout flow with four steps (Enter Shipping Address, Choose Payment Method, Review Order, Confirm Purchase), each with a handful of real cards under it, some already slotted into an MVP release, most sitting unscheduled. Nothing was staged for this test. It's the same structure from an earlier piece I wrote on story mapping basics.

Condition A: the bare prompt

Given only the ticket text, here's what came back:

As a customer, I want to add gift wrapping to my order at checkout so that I can send it directly as a gift.
Acceptance criteria: a gift wrap option appears somewhere in checkout, selecting it may add a fee (unclear), order confirmation should reflect the choice.
Open questions: where exactly does this go relative to shipping and payment? Is this a priority-one feature or something later? Per-item or per-order? Any specific persona this serves?

That's a perfectly serviceable user story. If you've used any coding agent to draft a spec from a one-line ticket, this will look familiar, it's fast, it's readable, and it's not wrong exactly. But look at the open questions. Every one of them is a real decision a developer will eventually have to make, and right now they're guesses dressed up as a to-do list.

Condition B: reading the real map

-> View the full size image
-> Open the interactive story map for more details

Same ticket, but this time the agent had tool access to the actual map: read the Checkout activity, read its four steps, read the real cards under each one, including which ones already sit in the MVP release. Three tool calls, all read-only, nothing modified. Here's what came back:

As a shopper, I want to add gift wrapping to my order from the review screen so that I can send it directly as a gift without doing the wrapping myself.

Almost the identical sentence to Condition A. That's worth sitting with for a second, because it would be more convincing for this article if the story itself came out dramatically better with context. It didn't. What changed was everything the story used to leave as an open question:

Placement stopped being a guess:
The Review Order step already held three cards: Order Summary, Cart Editing, Estimated Delivery Date, all order-level choices made right before confirming. Gift wrapping is obviously a fourth one. Condition A had "where does this go" as an open question. Condition B had it as a fact read off the map.
Priority stopped being a guess:
Every comparable optional extra already on this map (Apply Discount Code, Save Card for Later) sits in the unscheduled backlog, not the MVP release. That's a real pattern across two different steps, not a hunch. Gift wrapping followed it: reasonable to unschedule, not the walking-skeleton priority Condition A might have arbitrarily assigned.
No invented persona:
This map has zero personas configured. Condition A's blank "any specific persona?" question could easily have gotten filled in with something plausible-sounding but fabricated, "gift givers" or similar. Condition B just stated the actual fact: no persona split exists yet, so this serves the same general shopper as everything else on the map.

A second test: acceptance criteria

The user story barely moved between conditions, so I ran a second, narrower test on the same card: acceptance criteria. This is a better place to look for a real difference, because AC is where an agent has to commit to specifics, not just a placement decision.

Condition A, bare prompt, guessed AC:

Given a shopper is on checkout, when they select "Gift wrap this order," then the order is flagged as a gift.

Given the order is flagged as a gift, when checkout completes, then a gift wrap fee is added to the total (assumed).

Given the order is flagged as a gift, when it ships, then the packing slip excludes prices (assumed default).

Given the order contains only digital items, then the gift wrap option is hidden (assumed: this store sells both physical and digital products, and gift wrap doesn't apply to digital).

Four confident-sounding criteria. The last one is the interesting failure: it invents a fact about the product, that there's a physical/digital split, that was never established anywhere in the ticket. Nothing wrong with the sentence itself, it reads like something a real spec would say. It just isn't grounded in anything.

Condition B, grounded in the real map:

Given a shopper is on the Review Order screen, when they select "Gift wrap this order," then the order is flagged as a gift, alongside the other order-level choices already made on that screen.

Given the order is flagged as a gift, when Confirm Purchase completes and the existing Send Order Confirmation Email card fires, then the confirmation email reflects the gift wrap choice. Not a new integration point, it wires into a card that already exists later in this same activity.

Open, not guessed: whether gift wrapping applies to digital-only orders. Nothing on this map distinguishes physical from digital products, so this can't be answered from what's here.

Two grounded criteria, and one deliberately left open. That third line is the actual finding worth paying attention to. Condition A didn't leave anything open, it resolved every question, including one it had no basis to resolve. Condition B correctly identified which question the map genuinely can't answer and said so, instead of quietly making something up to look complete.

That's a better result than "the grounded version had more detail." A confidently wrong AC is worse than an honestly incomplete one, because the wrong one passes review and the incomplete one gets caught. Reading real context doesn't just fill in answers, it also tells the agent what it doesn't know yet.

Why this matters more as agents write more of the first draft

The user story sentence took maybe two seconds to generate either way. That part was never the bottleneck. The bottleneck was always the surrounding decisions, where does this fit, how urgent is it, who is it for, and those are exactly the decisions a raw prompt has no way to answer honestly. It can guess convincingly, which is arguably worse than guessing badly, because a confident wrong guess is harder to catch in review than an obviously uncertain one.

A persistent, structured map doesn't make the agent smarter. It gives the agent something real to read instead of something to invent. As more of the first draft of a spec gets written by an agent rather than a person, that distinction stops being a nice-to-have and starts being the difference between a ticket that's technically answered and one that's actually grounded in the product.

You can see the real map from this experiment here: the Checkout activity, the cards that grounded Condition B's reasoning, and the Gift Wrapping card exactly where and how it landed. The map has since grown into a full journey example (Browse Products through Order Tracking), but the Checkout section and the reasoning behind it are unchanged: Reading the Map vs. Guessing.

How Does User Story Mapping Work?

Tomi P. — Tue, 01 Sep 2026 13:05:21 +0000

If you've ever sat through a sprint review where three features are "done" but nothing actually works end to end for a user yet, you already know the problem I'm about to describe. You just might not have had a name for it.

The name is: your backlog is a list, not a plan.

I've been working with product teams long enough to have built more flat backlogs than I'd like to admit, and I've watched the same failure mode play out more times than I can count. So this is the plain, no-framework version of user story mapping I wish someone had handed me earlier back then. Let's keep things real: No 40-slide workshop deck, no certification required. Just the actual idea, and how to use it on your next project.

The problem with your backlog (and it's not the ordering)

Most teams treat prioritization as the hard part. Get the ranking right, work top to bottom, done. That's reasonable, except a ranked list throws away something important: the order a user actually experiences your product in.

Picture a typical backlog for a checkout flow. Forty tickets, ranked by priority. The team works through them in order. Three sprints in, you've built a genuinely excellent "browse products" experience: filters, sorting, a slick product page. And checkout itself? Barely started. Nobody can complete a purchase yet.

That's not a prioritization failure. Prioritization worked exactly as designed. It's a structure failure: a flat list has no concept of "this step needs to work before that one matters," so it's entirely possible to build one part of the journey beautifully while the rest doesn't exist yet.

A story map exists to fix that.

What a story map actually is

Jeff Patton popularized the technique (his book "User Story Mapping" is still the reference if you want the deep version), and the core idea survives being explained in about thirty seconds.

If you deliver software products that will be used by users, it is certain that you may have heard about user story mapping practices. If not, you may want to read until the end of this article to learn how user story mapping can be one of your best asset to support your product management processes.

User story mapping is a pivotal technique for bridging the gap between business objectives and development efforts, benefiting a spectrum of stakeholders including Product Managers, Product Owners, Business Analysts, UI/UX professionals, and most importantly, the customers themselves.

Understanding user story mapping is not merely about grasping its mechanics; it's about recognizing its transformative potential. By visualizing the user's journey and aligning it with product development. User story mapping facilitates clearer communication, enhanced collaboration, and more informed decision-making.

It acts as a bridge between diverse roles within an organization, ensuring that everyone shares a common understanding of the product vision and goals. Through this shared understanding, user story mapping enables teams to overcome challenges, prioritize effectively, and deliver solutions that resonate with user needs while driving business value.

User story mapping is a collaborative technique used in agile product development to visually organize and prioritize user requirements. It involves breaking down a user's journey into a manageable level (user stories) arranged in a map format, helping teams understand user needs, prioritize features, and align development efforts with business goals.

A story map has three layers:

The backbone, across the top: the big things a user does, in the order they'd do them. For checkout, that's something like Browse Products, Add to Cart, Checkout, Track Order.
The steps, one row down: what happens inside each activity. Under Checkout: Enter Shipping Address, Choose Payment Method, Review Order, Confirm Purchase.
The details, stacked below each step: the actual backlog cards. Under Choose Payment Method: Pay with Card, Pay with PayPal, Save Card for Later, Apply Discount Code.

That's it. That's the whole mental model. Everything else is refinement.

-> View the full size image
-> Open the interactive story map for more details

Reading the map two ways

The map rewards you for reading it in two directions, and this is honestly the part that made it click for me.

User Journey on the map

Read left to right along the top two rows, and you get the whole user journey visualized, literally: browse, add to cart, check out, track the order. It reads like a narrative because it is one.

-> View the full size image

Priority on the map

Read top to bottom under any single step, and you're looking at every way that particular step could be built, roughly ordered from essential to nice to have. Under Choose Payment Method, "Pay with Card" sits above "Save Card for Later" because you need one and can live without the other for a while.

-> View the full size image

Once you can read it both ways, prioritization stops being "which ticket number wins" and becomes "how deep do we go on each step, right now."

Slicing your first release (the walking skeleton)

This is where story mapping actually pays for itself.

Instead of building one activity completely before moving to the next (the vertical approach that got us into the browse-products-is-gorgeous, checkout-doesn't-exist mess earlier), you slice horizontally. Draw a line across the map at a certain depth and pull the top card from under every single step into your first release.

-> View the full size image
-> Open the interactive story map for more details

The result is thin. Pay with Card only, no PayPal, no saved cards, no discount codes. But it's complete. A user can go from browsing to a confirmed order, start to finish, even if every individual step is doing the bare minimum.

Alistair Cockburn's term for this is the walking skeleton: the thinnest version of the whole system that proves the architecture actually works end to end, before you spend weeks fleshing anything out. Build that first. If something's broken, you find out in week one, not week eight when three teams have already built features on top of a foundation that doesn't hold.

Thin and complete beats deep and partial. Every time.

What can go wrong

A few mistakes show up often enough that they're worth naming before you hit them yourself:

Starting from features instead of goals
If the first question in the room is "what should we build," you'll get a categorized backlog wearing a story map costume. Start with "what is this user actually trying to get done," every time.
Treating the mapping session as a one-off
A map built in a single two hour workshop and never touched again goes stale almost immediately. Treat it as a living document, not a deliverable you file away and forget.
Letting the map and the real backlog drift apart
If the map lives in one tool and the tracked work lives somewhere else with no connection between them, they diverge within a few weeks, and the map quietly becomes decoration nobody trusts anymore.
Running the workshop with the wrong room
Skip the engineers and the map ignores technical reality. Skip anyone who's actually talked to users and it reflects internal assumptions instead of real behavior. Get the right people in the room, or don't bother.

None of these are exotic failures. They're just the default, if you don't actively guard against them.

Where this fits in your actual workflow

Story mapping isn't a replacement for detailed specs, it sits upstream of them. The map tells you what the user is trying to do and in what order and depth you're building it. The spec or the ticket tells you exactly how. Both matter, they're just answering different questions.

Here's the part I think is genuinely new, not just a rehash of Patton's book with a 2026 date stamp on it: a lot of product teams are now writing user stories and acceptance criteria with an AI agent doing the first draft. That part is fine, honestly it's fast and it's usually decent. But a draft that lives in a chat thread has nowhere real to go. It doesn't know what step it belongs to, what came before it in the user's journey, who the persona is, or what depends on it. Close the tab and that context is gone.

A story map is exactly the structure an agent, or a person, needs to put that draft somewhere that persists: this card belongs under this step, under this activity, at this priority, for this persona. That's not a hypothetical for much longer. Tools are starting to let agents read and write directly into a real map instead of a disconnected transcript (StoriesOnBoard's MCP server is one example), which means the map isn't just documentation of a plan anymore, it's becoming the shared, structured place both your team and your AI tooling actually work from. The method doesn't change. What changes is who, or what, is reading and writing to it alongside you.

All in all

You don't need a certification or a two day workshop to get value out of this. You need a wall (physical or digital), an honest list of what your user is trying to accomplish, and the discipline to slice your first release horizontally instead of building one activity beautifully while the rest of the product doesn't exist yet.

Start there. Refine later.