User Stories That Don’t Suck

Ah user stories. The backbone of software development. When I was less than a month into my job as a business analyst, I had lunch with a product manager that informed me “everything starts with a user story.” It was a great lesson. Fresh into the technology world, I was looking to hold on to any wisdom I learned from experienced professionals. The user story became my best friend.

Yet, user stories can often get overlooked and can be seen as a given on projects. Teams just expect them to be written and be written the correct way. A team member picks up a user story, builds it, hands it off for quality assurance, and repeats the process. This process can be a dangerous trap; it can silo team members into mindless repetition. Ralph Waldo Emerson summarized it best, albeit in a wacky way, when he said: “A foolish consistency is the hobgoblin of little minds.”

At Revelry, we like to bring out the creativity in our individual team members. The commonly accepted way to write user stories is:

We’ve built upon this writing mechanism. Our goal is to outline clear directions of what we are solving with writing the user story with clear acceptance criteria. We like to push our people and see how creative they can be at solving a problem. Revelry’s user stories follow the framework of:

Who

Who is the team member solving a problem for? What are the specific needs of this person and why are they special? We want our team members to take into account the end user. Create it for an actual person, not a client they’ll never meet. That’s why we love having our clients in our office Revelry builds for people, not written requirements. It starts with the user story.

What

What is the team member solving? What is the action that the team member is looking to solve? Keep the workflow simple and avoid over-engineering software. Break the action into the smallest action that your user will do.

Why

Why is the team member solving this problem? The “why” is the most important aspect of the user story. It can be the difference between an engineer/designer simply displaying data on a screen and creating a beautiful feature. Seeing that “aha” moment of a team member understanding why they are creating software in the first place is a beautiful thing. It gives their work meaning, it gives them something to work towards.

Every user story needs criteria that all team members can sign off on and, once met, the user story can be marked as “completed.” We create succinct one-liners that allow quality assurance to have a clear way of knowing if a user story has been fulfilled. Anyone on your team should be able to hop into a user story, read it’s acceptance criteria, test the criteria against the software that was built, and know if the user story has been met.

Here is an example of a user story and acceptance criteria that we have written for our own use:

The reason we write user stories with this format is to take into account all stakeholders’ perspectives. User stories should be clear to a deisgner/engineer that will work on the story, the product owner who is driving the vision, and quality assurance who will test the software. The standard process of writing user stories can put engineers and designers in a repetition of fulfilling requirements and processing UAT. We want to break that mold.

Revelry partners with startups and corporations to deliver digital transformation and innovation.

Run an innovation sprint or build custom software.
We’re transparent about how we work. For a look at how we build digital products, check out
Lean Agile Processes and Tools.
Keep in touch by subscribing to CODING CREATIVITY.