The Trouble with User Stories

Does Anyone Know What a User Story Is?

So, we all know what a user story is, right? I mean, we all use them because that's the 'agile' thing to do (although neither the agile manifesto nor the scrum guide mentions anything about user stories). So, we should at least all agree on what a user story is. Let's have a look at what's the definition of a user story: 

• "User stories are short, simple descriptions of a feature" https://www.mountaingoatsoftware.com/agile/user-stories
• "A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective."  https://www.atlassian.com/agile/project-management/user-stories
• "User stories are very slim and high-level requirements artifacts." http://www.agilemodeling.com/artifacts/userStory.htm
• "..a way of representing bits of functionality required by the stakeholders in such a way as to generate the maximum amount of discussion among team members," https://manifesto.co.uk/agile-concepts-user-stories/
• "User stories are short and simple descriptions of capabilities" https://www.leadingagile.com/2012/07/user-story/

It seems that user stories can be a feature, a unit of work, high-level requirements, a bit of functionality, and a capability, depending on whom you ask! Also, bear in mind that the above various definitions are from agile influencers and blogs with thousands of followers. It seems no-one can agree on what a user story is. I often get different definitions of user stories by people within the same team!   

The reality is that we all use the same thing to drive our software delivery without understanding or even agreeing on what that thing is. It's like building a house where some builders refer to walls using the same term that other builders use to refer to floors. Chaos will inevitably ensue. And so it does. Most product backlogs I've come across are huge stacks of user stories describing a variety of things, from business goals to development tasks, from requirements to specifications, from problems to solutions. 

Let's see exactly why that happens.

User Stories are Difficult to Scope

Let's look at the following:

xxxxxxxxxx

As an end-user 

I want to log-in with my social media credentials

so I don't have to remember extra usernames and passwords

And now this: 

xxxxxxxxxx

As an end-user

When I log-in I want to be re-directed to the login page of my selected Identity Provider

So that, upon entering my credentials, the IP can redirect me back to our system with a valid SAML token

What's the difference between them? They both describe the same thing. The difference is in their scope. The first one is scoped at a high, business-sponsor, level. The second one is scoped at a much lower, developer, or tester level. But they are both valid user stories. Many people use the INVEST guidelines to try and scope stories in a useful manner. However, these guidelines are open to interpretation, just like user stories themselves. For instance, both the stories above are INVEST-able (the 2nd one arguably more than the first).

User Stories Hide Real Value

Here's a story:

xxxxxxxxxx

As a blogger who codes, I want the blogging system to integrate with GitHub so that readers can see my GitHub activity in my profile.

This story muddles up the What, How, and Why. It mixes the end with the means. There is a stated objective: 'readers see bloggers coding activity'. The question is: does this help the blogger reach their goals? Well, we don't know what their goals are because the story doesn't tell us. The story hides the goal behind an objective. The objective is not the goal. The tactic is not the strategy. The output is not the outcome. Should this story be?

xxxxxxxxxx

As a blogger who codes, I want my GitHub activity to be displayed in my profile, so that readers can see that I'm a prolific coder and read my posts

It could and it should, but user stories are such a wonderfully vague and generic device, most people would accept the first version and get on with it.

The 3Cs  guidelines suggest having a conversation around the user story. This is great advice and an experienced analyst will quickly discern the actual goal in this story. However, many people will be just happy to agree that this story is good enough as is and proceed accordingly. 

User Stories Conflate Problems with Solutions

Let's look at an example: 

xxxxxxxxxx

As a reader, I want to bookmark pages so that I can quickly find relevant content in the future

At first sight, this story looks fine. It has a user role, an activity, and a goal. However, this story not only describes a problem but also suggests a solution (bookmarking). Is this the only solution to the problem?  Are there other, potentially better solutions? By using this story as our requirements input, we will never know.

User Stories are Difficult to Prioritize

Most backlogs are full of story cards. They're all written in the same template and they describe a wide range of problems and solutions. They are widely scoped (if we're lucky the more complex ones will be marked as 'epics') and they provide a little context as to the business need behind them. Want to prioritize them by value? We have to sift through all of them, looking at their 'goals'  (even though these goals may not be valid, see previous sections) and translate these goals to 'value'. Want to prioritize them by cost? Then we need to come up with estimates. If we're lucky enough to have a specification for a story, then we may make an educated guess. Otherwise, we do what most people do and give a finger-in-the-air estimation (a.k.a planning poker). Again, we have to go through lots of stories to be able to gauge their comparative value or cost. 

User Stories are Difficult to Classify

Want to classify the stories and place some structure and sanity on the backlog? We can easily classify per user role (the 'As a user' part) but anything else requires another sift through the backlog, trying to discern patterns of value or functionality under which we can group stories. User stories don't provide any means of classification of organization, other than the user-role. To give our backlog any kind of structure we need to come up with ways of discerning patterns and categories in our stories. The lack of explicit scope and value in user stories (see previous sections), makes this task even more difficult. Story Mapping is a great way of making sense of the story-based backlog chaos, but this is yet another activity we need to do just because we use the wrong abstractions to capture requirements.

So, What's the Story?

Why do we still use User Stories, more than 20 years after they were conceived and when we still can't agree on what they represent? The simple answer is: because that's the way it's always been done! Cultural acquisition works with software developers as with rhesus monkeys.  Can we do better though? Sure we can. By identifying and modeling appropriate requirement domain entities with an impact map, we can accurately and reliably capture requirements and bridge the gap between them and specification, while creating a visual, hierarchical, and traceable requirements model.   

• Business Goal (Why): The intended benefit of our system
• Stakeholder (Who): Someone who is affected by our system
• Capability (What): A system ability that enables the Stakeholders to achieve a business goal
• Feature (How): A functionality that helps deliver a Capability

And, just like that, we have well-defined Requirement Domain Entities and a clean backlog. Our requirements are represented by Capabilities in the context of Stakeholders and Business Goals.

We can then use the Features as the starting point of a Behavior Driven Development cycle, to create our specifications and verify our delivered code.   Our specifications are the fully-formed Features, which describe the system functionality we will implement to deliver the system's capabilities. A Feature may be described by a User Story followed by several scenarios/acceptance criteria. But a Feature is not a User Story!  Let's stop using stories as catch-all requirement analysis and capture device and let's start referring to the actual requirements domain entities these stories represent.