{{announcement.body}}
{{announcement.title}}

The Trouble with User Stories

DZone 's Guide to

The Trouble with User Stories

User Stories are a vague, subjective and generic way of requirements gathering and analysis. This article examines their negative impact and what we can do to make it better.

· Agile Zone ·
Free Resource

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: 

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. 


user story hell

User Story Hell

Let's see exactly why that happens.

User Stories are Difficult to Scope

Let's look at the following:

Markdown
 




xxxxxxxxxx
1


 
1
As an end-user 
2
 
          
3
I want to log-in with my social media credentials
4
 
          
5
so I don't have to remember extra usernames and passwords


And now this: 

Markdown
 




xxxxxxxxxx
1


 
1
As an end-user
2
 
          
3
When I log-in I want to be re-directed to the login page of my selected Identity Provider
4
 
          
5
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:

Markdown
 




xxxxxxxxxx
1


 
1
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?

Markdown
 




xxxxxxxxxx
1


 
1
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: 

Markdown
 




xxxxxxxxxx
1


 
1
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.   

A Requirements Model

A 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. 

Topics:
agile methodology, behavior driven development, impact map, requirement gathering, requirements analysis, user stories, user story

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}