The Liberators
Published in

The Liberators

User Stories are all about the conversation, not the actual thing you write on a card or put in JIRA

The purpose of User Stories in Scrum

Most of the backlogs I work with are made up of user stories. Although they are in no way required for Scrum, they are a useful technique to describe functionality in a just-detailed-enough manner.

But many seasoned analysts and architects cringe at the idea of having to write user stories. To them, it feels like a very sub-optimal and forced way to capture the richness of user requirements. And I completely get that it feels fishy to write user stories, only to have the Development Team come in and ask a ton of questions when they start working on it. Wouldn’t it have been more practical to have captured all the details of the functionality beforehand?

And you know what? This is a valid point,

It is a valid point if you treat User Stories as the only way to specify user functionality. And this is where we run into an important misconception about User Stories. A User Story is not meant to be a complete specification. It serves different purposes:

  • A starting point for meaningful conversation and collaboration about what the functionality should be like, assuming that the best way to clarify intent is by talking about it as analysts, developers, architects and product owners
  • Provide a functional overview of what the application will be able to do for users, so that the team can (roughly) estimate the work and allow the Product Owner to prioritize quickly
  • A way to describe functionality in the simplest way possible so that teams don’t get bogged down in writing and updating specifications whenever scope changes — and it always does

User stories are not supposed to replace complete specifications with a magical method that achieves the same result in a fraction of the time. They are meant as a starting point for further refinement and specification by Scrum Teams. User Stories fit with the Just-In-Time specification that happens in experienced Scrum Teams. They have learned that the best moment to further specify functionality is when they are about to get started on it. Preferably not by passing along specifications on paper (or in a tool like JIRA), but by discussing intent, implementation and test scenarios within the team. It’s perfectly fine if a team then decides to write this down (on paper or in a tool) in the form of a use case, a workflow, a SpecFlow scenario or some other specification. But in this case User Stories have served their purpose; to initiate communication and share knowledge, so that the team can continue building valuable functionality.

You can already support us with $1/month. Find out more on



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store