A Quick Guide to Avoid the #1 Mistake With User Stories

Here’s how not to confuse them for requirements.

Output is a fixation we can’t seem to shake in the product space.

We continue to think we know the right product to build before we build it. This often shows up in the way we treat user stories as requirements.

Even though many product teams and managers think user stories are requirements, they aren’t. The output-oriented among us (I’ve fallen into this trap myself) are notorious for saying:

• “But the user stories have acceptance criteria to meet the requirements.”
• “But the user stories must trace back to the user requirements.”
• “But the user stories show we’ve done what the user wants.”
• “But the user stories represent what the stakeholders demand.”
• “But we have delivered outcomes when we complete user stories, right?”

It’s practically an epidemic how many in the product world mistake the user story for a user requirement.

And here’s why:

Output, output, output.

Output is tangible and in our control. The outcome is not. We latch onto what we feel we can control.

Imagine you are a chef who has a list of dishes to cook. You’ve been cooking for many years, and you’re an expert. You line up all the ingredients. All elements are sliced, chopped, and diced. The right proportions of seasoning are measured out. You expertly prepare your dishes and present them on the plate with care. Have you met your requirements as a chef?

The chef here has forgotten the consumer, just as we forget our user when we treat the user story as a requirement.

Look at all the ways we fall into the trap of output fixation:

• OKRs
• Goals
• Tasks
• Points
• Stories
• Tickets
• Velocity
• Planning
• Features
• Backlogs
• Forecasts
• Deadlines
• Estimation
• Cycle time
• Prioritization
• Requirements
• Benefit Projection

It’s all output and ensures no outcome.

Many argue that user outcomes can’t be realized without output. So, we put all our energy into listing requirements, planning, and building to a checklist.

So, here we are, confusing motion for progress.

If the user doesn’t use what we build, nothing matters.

Said more specifically: users don’t care that you delivered everything you set out to do. They don’t care if you deliver it all on time. They see no value in how much effort you put in or the experience you have. If your product doesn’t delight them, you’ve lost them. They are the diners staring at the chef’s dish of exquisitely prepared seafood when all they wanted was a nice juicy steak. So, they leave and don’t return.

Nothing kills more products or costs a company more than blindly treating user stories as requirements.

Don’t forget that.

This year, I’ve committed my focus to a concept called Lean Leverage, as described in my inaugural 2024 post. Each article I craft this year, including this one (the 16th in the series), will focus on an aspect of Lean Leverage. Enjoy and stay tuned for many ways to do more with less.

A Quick Guide On How Not To Confuse User Stories With Requirements

So, now that you understand the urgency of the user story as requirements problem, let’s talk about how to solve it.

And let’s create true fans of what we build.

#1: Be Clear About What User Stories Are

To overcome our obsession with user stories as requirements, we must first define “what they are.”

You may have heard the statement from Mike Cohn, “User stories are placeholders for conversations.” To me, this is much closer to how we should treat a user story instead of as a requirement. It says we don’t know the answer. The answer can only be arrived at through conversation. And not by just one conversation, but many.

User story conversations happen between teams, customers, and stakeholders.

• What would make this part of the user workflow easier?
• How can we reduce user error here?
• Can we A/B test two solutions?
• How does this work (or not) today?
• What did we learn from the user that we can apply to this now?
• Does this have the potential to impact our business?
• Why would we spend time on this now that we have this evidence of a better path?

Notice the uncertainty in the conversation. See how evidence is being used to chart the best next move. Context is everything, and context is always shifting with new data arriving at a rapid pace.

User stories are options.

They are placeholders for conversations.

And no user story is anything other than output to try to solve a user need.

#2: Be Clear About The Reality Of Requirements

The second thing we need to do is get clear about the reality of requirements.

Requirements don’t mix with the uncertain complexity of product development.

• How can we know what every user need is?
• How can we know the solution that will strike the right balance of simplicity and effectiveness?
• How can we know a solution is great before it is used?
• How can we know it is useful if users don’t keep using it?

It doesn’t matter how sure you are about a user need, an idea of a great feature, or a solution you’ve seen work before. Until it’s in your user’s hands in the wild, you won’t know the outcome. While this sounds like common sense, it’s not common practice to let the user guide our efforts.

The only real requirement is to make a difference to our users and not lose sight of this.

#3: Be Clear About What It Means To Be “Done”

“We met all the acceptance criteria in the user story. We did our part and met the requirements. We are done.”

Yawn.

This is output fixation and a do-what-you’re-told mentality. Unfortunately, it exists everywhere. It’s language that centers around a fixed-scope mindset, and we need to shift our perspective. We need to be less satisfied with following a recipe.

Instead, just say:

• We must get this into our user’s hands and get some feedback.
• Are users using the features we just released?
• Are users coming back to it over time?
• What are users saying about that feature?

Boom. Now we care about “Done” from the user’s perspective.

We move away from focusing on completing tasks, or doing what is in the backlog, or delivering on time. Instead, we must push to get signal from the user. This tells us whether we are making a difference or not. This tells us if we have to go back to the drawing board and start over. We want our dish to make the user’s tastebuds sing.

Done is delighted.

#4: Be Clear About Emergence

And finally, you need to accept that you don’t know the answer.

Finding the solution that makes a difference requires trial and error.

1. Start with the essence of a solution, no adornment.
2. Get user feedback.
3. Relentlessly pivot based on feedback. Throw out what doesn’t work. Keep what does.
4. Evolve detail where needed, no more.
5. Get user feedback and refine until desirable. Stop.

The best solution you can imagine may not be what the user needs in the time that they need it.

Engage with your user before, during, and after you build a solution.

Evolve from a place of good and stop when good enough to delight.

And you still may be wrong, but this is the game of product development. It’s a wild ride, but worth it.

---