What are User Stories?

Howdy, Upstarts!

For anyone building a new product or working in startups, there are a couple of pieces of jargon that will keep rearing their heads. In general, jargon is fine, except when it becomes a distraction; from my personal experience, I have seen meetings quickly become derailed while people get into debates over semantics. I have always found it helpful to ensure that my teams are on the same page when it comes to the definition of any jargon before we resort to bikeshedding.

One of the most notorious pieces of jargon amongst Agile Development Teams, SCRUM Masters, or KANBAN Gurus is User Stories, which is unfortunate because User Stories are one of the most powerful tools for your development team!

So in this article, I want to take some time and provide an explanation of what a User Story is and how you should be using them to build your technology product.

… So, What are User Stories?

A User Story is a definition of the requirements for a piece of work for a team member.

It defines what needs to be done!

User Stories define what needs to be done for a new feature. User Stories define what needs to be done to fix bugs. User Stories define what needs to be done to design a new screen or button. User Stories define what needs to be done for infrastructure upgrades or database migrations.

That means that the User Story should, in general, provide all of the information for a developer or designer to complete their task.

… So, How do I Write a Good User Story?

The crux of a good User Story is to provide enough information for any developer reading it to understand what they need to accomplish with their work while needing to ask a few questions as possible.

So when I sit down to write a User Story, I want to make sure 1) that my User Story has a clear structure and 2) that my User Story conveys all the information that is necessary for my developers.

To communicate clearly, I organize my User Stories into sections, like chapters in a book; and just like a book, I need enough chapters to tell the whole story!

The first section that I write is a Background Section. I use this section to provide the context of the challenge that needs to be solved.

The second section that I write is a Goal Section! I use this section to provide a clear and concise description of the business requirement that I want to achieve.

It is important to see that so far, I have not provided any explicit engineering tasks, only business requirements! This frees my developers of preconceptions and gets them solving my business problem with their own talents and creativity and without any of my own biases!

The third section that I write is the Deliverable Section! After I provide enough context for my developers, I use this section to give them a concrete, software deliverable such as a new API endpoint or visual component.

The last two sections that I write are a Resources Section and a Reference Material Section! In these sections, I connect my developers to designs and wireframes or third-party integration guides or company documentation. These sections are to give them additional tools and information that is more general, but not specific to my User Story, although they are thins that I want them to know.

So let’s recap!

A Good User Story is divided into clear sections that communicate:

1. Background

2. Goal

3. Deliverable

4. Resources and Reference Materials.

But what is a User Story For?

I began my career in the US Defense Industry, which focuses on creating incredibly detailed requirements definitions. Most defense contractors spend hundreds of thousands of dollars on highly complex software tools to track their contract requirements! But after I left the defense industry, I moved to Austin, Texas, and began working with technology startups, who work with agile processes, which are much more focused on in-person conversations to define requirements. The product managers that I was exposed to in Austin shunned the highly specific and detailed requirements that were favored by product managers in the defense industry, and my peers from the startup world preferred to handle any explanation on an ad hoc basis.

Both approaches were problematic because managers form the defense industry spent much of their time managing the minutiae of phrasing and contract language, while managers from the startup industry spent much of their time repeating explanations and conversations with different team members.

A good User Story should strike a balance between detail and flexibility, and it connects the needs of the business with the technology of the product!

A User Story is the primary channel of communication between product managers, the people with the business knowledge, and developers, the people with the technical knowledge. Imagine a User Story like a bridge that crosses a river, on one side is the business knowledge, or what the product needs to be able to do, and on the other side is the technical knowledge, or how the product can do it. A User Story is a road that connects these two fields of knowledge in the most productive way possible.

Because the person that usually writes a User Story is the product manager, the master of the business knowledge, a User Story is about bringing business knowledge to the developers!

As long as you keep this philosophy, you can change the structure that I described in the previous section to fit the needs of your engineering organization!

If you Communicate Clearly, Then you Can’t Go Wrong!

In this article, I reviewed one of the most common and important pieces of jargon in Agile Software Development: User Story. And I reviewed how to write a good User Story that your developers can use to quickly deploy new features for your technology product.

But more important than an Instruction Manual, I hope that I have often explained the underlying philosophy of User Stories, and what they need to accomplish! With this understanding, you should be equipped to create a clear point of contact between your product team and your development teams!

Even though it is daunting, if you invest in clear communication, then you really can't go wrong!