How to Harness User Stories (the Right Way!) to Ensure Agile Project Success

  Adam Franklin, Technical Architect at HIKE2

Throughout your career, you may be involved in lots of different projects for many different stakeholders — from huge, global initiatives with hundreds of people in many countries to small, quick projects for local nonprofits.

No matter the client, there are some commonalities.

A stakeholder in the business or the IT organization has an idea that could improve their workflows. They want to guide the organization to some kind of change.

In every case, organizations have to first find a way to explain where they want to go and then collaborate with IT departments, the business, and other stakeholders to determine:

1. Are we going to the right place?
2. If so, how will we get there?

That need to communicate and collaborate is fundamental to every project we do — whether we’re a stakeholder, the person responsible for delivering it, or someone in between.

How Innovation Through Simplicity Happens

Revisiting this theme of simplicity from the 2022 Innovation Summit keynote, when we work as a team, it’s pretty helpful if everyone’s working towards a shared goal.

If one or more team members aren’t on the same page, it can lead to confusion — or worst case, the wrong product being built.

And if you’re the client, misunderstandings can cost a lot of money.

Getting to a place of shared understanding isn’t really complicated, but it does take time as well as thought, planning, and intention.

We have most of the tools we need already — if not, a quick trip to an office supply store will solve that pretty quickly.

We can use these simple tools to form our shared understanding of our destination, chart our course, and map out our way points.

But first, we need to provide a structure for everything that’s to come.

Three Big Ideas of Shared Understanding

There are three main compass points to creating shared understanding:

1. Stories are the starting point for a conversation
2. The goal of user stories is shared understanding
3. Externalize your understanding — it’s the agile way

Let’s look at each of these in detail.

1. User stories are the starting point for our conversation

User stories refer to what software does — for example, when you enter a zip code, a program automatically fills out city and state. That’s one simple story.

They’re the starting point for a conversation with stakeholders, giving them the opportunity to improve or change something.

But over time, the idea of user stories has been opened to a wide variety of interpretations. Now it seems everyone has a different idea.

Some interpret it as, “We can document less because now we’re agile,” but that’s not entirely true.

Others think the magic comes from writing the story in a prescribed format, but that doesn’t really achieve anything other than forcing us to contort our thinking into a template so we can say we’re “user-focused.”

Still others think it means they can almost skip over the requirements and just start rapid prototyping without really having a good understanding of what’s needed. We do want to be iterative, but that kind of thinking still misses the moment.

In reality, the user story should be the starting point for conversation.

Through conversations, we validate our understanding in real-time and get fast feedback on how close we’re getting.

We invite everybody else to understand the problem and build a more collaborative effort.

So while we do need to adhere to some kind of structure, what matters most is how we use stories, not how we write them.

2. The goal of user stories is shared understanding

This might be a new way of looking at things, but what’s written down initially isn’t of primary importance.

It matters, but having a conversation matters more.

The conversation is where the discovery and understanding happen. It’s where we flesh out the ideas or activities in an interpersonal context.

Conversations should be as deep as necessary, not shallow, 30-second touchpoints. We should take enough time to illustrate our ideas and think through the details. They should involve more than just one or two people and instead get everyone involved.

And remember, the outcome we’re after is shared understanding.

That means the process, those conversations, will likely change the destination a bit — and that’s a good thing.

Once we’ve built that shared understanding, we need to create a record of it — ideally, using a combination of graphics, video, and written summaries.

As an example, a vacation photograph represents an experience. You can’t replace the entire trip just by looking at a photograph. There’s no way to know all the experiences that led up to the moment that the photo was taken.

In the same way, the documents that we create from our conversations around user stories function like a photograph. They don’t contain all the details — but they remind us of those details if we were part of that experience.

The best documents we create from our conversations will help us flesh things out further and recall details, but they don’t replace a conversation.

In many projects, people tend to believe that the goal of user stories is to “do” agile, as in:

• User stories are the way to capture requirements
• We need a backlog of user stories to determine the project scope
• User stories are part of SOWs to show why projects are a lot of work
• Creating user stories is part of what we agreed to do
• User stories are a way to break down the work into deliverables that developers can implement within a single sprint

But we know better.

Stories do help us with all these things. They help us implement agile practices, and they provide a structure for organizing requirements around shared topics. They can be broken down into smaller deliverables within a sprint.

And yes, some stories should be in a backlog, but that isn’t their main purpose.

Their main purpose is to create shared understanding facilitated through conversations.

We get that by validating our understandings and providing opportunities to get feedback on it.

3. Externalize Your Understanding

This last point might seem a little controversial.

Business analysts often work hard to capture requirements in documents that conform to what they’ve been told are best practices.

Yet when things go wrong, the common refrain is, “Environments weren’t good. It wasn’t in the story, so it wasn’t needed and it didn’t get built.”

As Jeff Patton likes to say, “Shared documents are not shared understanding.”

Whether you’re on the delivery side or the business side of a project, you can be sure somebody has a folder of requirements and analysis including what the old system did and what they want the new system to do.

And those documents might be fantastic — well organized and thoughtfully assembled. Maybe they used a nice template and were carefully edited.

But did all that care and attention actually lead to a high-quality outcome?

When we read documents as individuals, there’s no way to know if we’ve interpreted them the same way.

We don’t know which salient details could have been overlooked or even just forgotten.

Maybe we looked them over studiously right after kickoff. But three months later, when we’re actually building the solution, not everyone will have read those documents.

• Sometimes the budget doesn’t allow time for everybody to go over the docs
• Sometimes the docs aren’t helpful and the team knows better
• Sometimes people try to read them but their brains shut down after 10 minutes
• Some folks get involved midstream and they don’t have time, or they try but it’s all decontextualized — they don’t have enough background

This graphic demonstrates the problem with requirements documents:

Bring everyone together

In most projects, many people say nothing at all. They might think they understand what they’re looking at, but someone else is interpreting that information in a very different way.

That’s why externalizing understanding is so important.

We need to put it out there in a form that others can respond to — for example, we can use a whiteboard to identify that we don’t all have the same understanding of the goal.

We can identify where the disconnects are and which differences we need to address:

• What did you pick up on that I didn’t?
• What should we be excluding?
• What did you think we meant that we actually didn’t mean?

Once we have it all out there, we can confirm our understanding together.

As in agile software development, one of our goals is to validate our understanding of the topic and get our feedback quickly so we can adjust accordingly.

That means we should check in on our understanding frequently.

Course correct in small increments.

Don’t over-commit in one direction and then get whiplash going somewhere else.

Use Simple Tools and Processes

How? There are a couple ways.

1. Diagram stories in real time

Stakeholders love this approach. You don’t have to have mastery of UI or sequence diagramming or even UPN business process mapping for any of this to work.

You just need to be able to document enough to show your understanding of a process outside of your brain so that others can look at it.

You can use a whiteboard, Elements.cloud, Miro, Lucidchart, etc. It’s up to you.

2. Record your understandings

It’s not really useful to record entire meetings. Rarely does anyone go back to listen. Instead, record short bursts of focused understandings.

The advantages of this approach:

1. It gives the client another opportunity to say, “No, that’s not quite right.”
2. If someone is joining the project later, they can find exactly what they need.
3. It’s a good reminder to yourself without having to sift through an entire meeting recording.

Even if you don’t record, at least say it out loud. You’ll find nearly the same benefits as recording.

Finally, draw pictures. They don’t have to be good, just enough to convey something meaningful. Often pictures convey more than words. Use both.

Whatever you do, make sure it’s in a shared context where other people can see what you’ve written and provide feedback.

Stick with the Basics (They Work!)

You’ve probably heard many of these ideas before — and that’s good.

That means it should be easier for you to integrate them into your thinking and apply them.

If you’re interested in digging deeper into any of these topics, you’ll want to check out books and videos by Kent Beck, Jeff Patton, and Ron Jeffries.

But if you take nothing else away, remember —

Stories are the starting point for conversations.

Have them early and often.