(Originally written in 2018, but still relevant today)

It’s become somewhat fashionable to gather requirements in User Story format to put into a product backlog. Pioneered some time ago in the early days of Agile, Extreme Programming, and other uprisings against the Great Gathering of Requirements up Front before starting work, it had a purpose that seems to have been lost in a few organizations.

Simply put, the expression of a requirement through the standard User Story form of “As an X, I want Y so that Z” was meant as a starting point, not an ending point. I’ll return to that point later, but I wanted to write about how I’ve seen them used (or abused) through a blind devotion to this form. I recently walked past an entire whiteboard full of Post-Its, all in the User Story form, at a client’s office.

The challenge to any development team has always been about taking some client need and translating that into a product. That client need may be well- or poorly-defined. It may be devoid of technical jargon, or full of it — it doesn’t, and shouldn’t matter to the development team. Identifying the existence of a need, and having a process where this need can ultimately be fleshed out and realized, is simply all there needs to be. At least in an agile environment.

The misuse of User Stories as a way to express requirements can be problematic in many ways:

1. User Stories can be too granular. I’ve seen individual User Stories for an administrator to add a product, edit a product, delete a product, and so on. Each discrete function was expressed as a User Story, ballooning the number of user stories when maybe all there needs to be is an overarching “As an administrator, I would like to manage products” User Story.
2. Excessive granularity can take away from taking a more holistic view of the requirements. By individually specifying each step of the journey, it’s hard not to look up and around you rather than focusing down at your feet; spotting the right destination may get a lot harder, reducing agility.
3. User Stories can cross into specifying the “how” to do something (the realm of the Development Team), rather than the “what” or “why” (the realm of the Business / Customer).
4. Innovation and creativity could get stifled or limited by the way the User Story is written. Even without specifying UI or system design, the User Stories could subtly influence the way the Development Team builds the system, rather than taking a more agile and open approach. Using technical concepts that could translate into programming concepts may reinforce this tendency, such as specifying a desired user workflow from one page to the next.

A User Story that is not appropriate to be worked on can devolve into confusing or heated planning meetings with all parties struggling to come to a consensus on how to implement it.

There are several approaches to solve this problem:

First, understand that in Scrum, the Product Backlog can be composed of anything, tasks, bugs, and yes, User Stories. Free your mind that Product Backlog Item == User Story. (Ignore the fact that JIRA calls its main trackable units of work User Stories, so they have to answer for this).

Next, figure out how you want to use User Stories.

1: Find a way to satisfy the development team’s definitions of what they need when they start building something. They might not need much if they are an agile team and the business has subscribed to being agile (in this case, starting work with just enough requirements to get going, and having the attitude to figure things out along the way).

2: Recast the role of the User Story as a conversation starter for capturing ideas. This helps to frame the User Story as something that is valuable for the business to help initiate something in the development team. The development team can also understand the User Story because of the simplicity, and can possibly start imagining how it might be implemented.

Applying the 3 C’s Model (Card, Conversation, Confirmation) can help with establishing the contents of a User Story. In fact, very little needs to be there to initiate the conversation.

Lightening the load of the User Story makes it easier for whomever is writing it out, and gives much more leeway for the development team to start asking questions and moving towards being able to estimate effort.

3: Use detailed User Stories as additional documentation to help capture a solid list of requirements for developers. Encourage developers to look at the repository of User Stories for additional insight or context information. Examples of usage, especially when there are detailed calculations that are performed by the software, are fantastic in the user story. This gets the whole team towards Specification by Example, or Behaviour-Driven Development processes that are ways to work with the stakeholders.

Express User Stories in business-speak, in broader terms.

Applying this to Sprint Planning and the Product Backlog

Warning:

Some tools even reinforce this User Story centric point of view; JIRA, for example, makes the User Story the topmost estimatable item in the backlog. Tasks belonging to a parent user story can’t be estimated, an annoying limitation.