DEV Community

Fred Heath
Fred Heath

Posted on • Edited on

Enough with the User Stories already!

The fog of Agile

Agile, at its core, is a set of guiding principles that are interpreted by the creators and practitioners of various processes, methods and frameworks. Like a language with many dialects, this results in the same word meaning slightly different things in each dialect. Asking the question "what's a user story?" will give you a dozen different answers. A user story can be a requirement, a feature, a description, an end-goal, a high-level abstraction, a small piece of business value and many other things, depending on who you ask - and when you ask them ;)

I tend to agree with Mike Cohn's definition: A user story is a description of a feature. Of course, this only moves the question to "what is a feature?". A quick Googling shows us that definitions abound: a feature is a functionality, a capability, a requirement, a client-valued function expressed in the form , a part of an Epic, etc. And so it goes on and on.

Here's a common pattern I've come across many, many times and I'm willing to bet that you have too: A stakeholder asks to look at the 'user stories'. The stakeholder later returns complaining that the user stories are too technical or too abstract or that the wrong actors are involved

Here's an example:

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
Enter fullscreen mode Exit fullscreen mode

That's a user story, right? You can give this to your stakeholder but they'll probably complain that this is too generic to be of any value. And they'll be right. You then give them this story:

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
Enter fullscreen mode Exit fullscreen mode

The stakeholder looks at you blankly. You don't understand what the problem is. They wanted User Stories, you gave them User Stories, so WTF? The thing is, the stakeholders want something very specific but they don't have the right words to express it because User Stories is a loaded term. Let's hold that thought for a minute.

A Requirements Domain Model

In his BDD in Action book, John Ferguson Smart elaborates on the usage of Impact Maps, a technique introduced by Gojko Adzic that is useful for answering the big questions of the Requirements and Specifications model:

  • Why are we building the system?
  • Who benefits from it?
  • What do we need to build?
  • How will we build it?

These can be directly translated to Requirements and Specifications Domain Entities:

  • 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 Domain Entities. Our requirements are represented by Capabilities in the context of Stakeholders and Business Goals. Our specifications are the Features, which describe the system functionality we will implement in order to deliver the system's Capabilities. In true BDD fashion, a Feature is described by a User Story followed by a number of scenarios/acceptance criteria. A Feature is not a User Story! We can use User Stories to describe Capabilities, Features and Business Goals too.

Impact Map

  1. Our system Requirements are the Capabilities in the context of the beneficiary Stakeholders and valid Business Goals
  2. We can describe Capabilities and Business Goals with User Stories. This doesn't mean that the stories are these things.
  3. Our Specifications are descriptions of the system behaviour required in order to deliver a Capability, i.e. the Features

User Stories are just descriptive devices for Requirements Domain Entities.

So let's jump back to our confused stakeholder. When they asked you for User Stories, what they were asking for was the Features! They wanted a description of the system functionality that you'll provide in order to enable them to achieve their goals. Nothing more, nothing less. User Stories are not Domain Entities, they are just descriptors. We need to start communicating using Domain Entities, not descriptors.

So we provide the following to our stakeholder:

Feature: Login with Twitter
As a end-user with a Twitter account
I want to log-in with my Twitter credentials
so I don't have to know extra usernames and passwords

  Scenario: First-time login with Twitter, already signed-on
    Given the user visits our system's login page
    And the user hasn't signed-on our system with Twitter before
    And the user is not already signed onto Twitter
    When the user chooses to sign-on our system with Twitter credentials
    Then the user is presented with a Twitter login page

  Scenario: First-time login with Twitter, not currently signed-on
    Given the user visits our system's login page
    And the user hasn't signed-on our system with Twitter before
    And the user is already signed onto Twitter
    When the user chooses to sign-on our system with Twitter credentials
    Then the user is presented with a Twitter permissions and confirmation page

... (more scenarios)

Enter fullscreen mode Exit fullscreen mode

Note how we present a User Story beneath our Feature title in order to best describe and illustrate our Feature. Also note that our Feature would still be valid and usable even if we didn't use a User Story. The User Story is not the Feature! It just gives us a nice narrative so it's useful to use it in our Feature. But that is all. We're not creating User Stories, we're defining Features.

As Developers, Product Owners or Business Analysts we get flooded with our clients' wishes, needs and desires. Our first question should be: "What should the stakeholders be able to do with our system in order to fulfil their wish or need?". Once we've answered that, our next question should be "How are we going to deliver that capability?". The result of this thought process will give us a set of Specifications (Features) that realise the stakeholders' requirements towards achieving some Business Goals. So let's clear the fog and start talking more about Capabilities and Features, instead of their generic and variant descriptors. Enough with User Stories already!

Latest comments (44)

Collapse
 
stereoplegic profile image
Mike Bybee • Edited

Personally, I think this illustrates just how needlessly convoluted the entire process is, and why I think anybody who has the opportunity and time to spare should spend at least a few hours a week in some capacity (founder, advisory, fractional CTO, part time freelance dev, whatever) with a tiny, early stage startup. You learn a great deal about what is absolutely necessary and what simply won't fly in such an environment, and it can revolutionize how you approach problems in environments at any scale.

PM methodologies are merely sets of tools. Use the ones that make your work easier, and discard those which do not. If you follow any methodology like religious dogma, you're missing the point entirely.

Much of this can be drastically simplified just by adding a product backlog/icebox to a Trello board that only the lead/architect/PO/PM/CTO(/wearer-of-many-hats) can move into the sprint backlog (ideally after refining to a much simpler extent than discussed here, and only after conversing with whatever dev team there is).

User feedback can feed directly to this product backlog from a simple feedback form in the app via Trello API, where feedback categories map to Trello card labels, with user contact info captured for follow-up as needed for refinement.

It really doesn't need to be all that complicated.

Collapse
 
dionei_piazza profile image
Dionei Piazza - be.yourself💡

Hey, has anyone here heard of Jobs-to-be-done? Jobs stories? Here is a link that may interest you all. It is a different way of understanding and describing a deliverable. I hope I helped you!

jtbd.info/replacing-the-user-story...

Collapse
 
agile_mercurial profile image
Joshua Render

Nothing in Agile requires a User Story. They get used because they are supposed to be simple and easy to understand. The largest problem with them I think is people overthink things with them. Then they create specific ways they must be done. Then they become so concerned about the rules and the proper way to make one

It needs to be simple, it needs to be understood by the team. Those are the only rules that matter.

It doesn't need to explain everything about the application and how you are getting to where you are going, you don't need user stories for all the little details. If the "As a ..., I want...., Because..." format doesn't work well - don't do it that way.

"We need a secure way to create our user accounts to protect customer data."
*Then list some of the details here.

Collapse
 
jamesapeters profile image
jamesApeters

What if the end-user's request adds up to just providing a SEO (Search Engine Optimization)? I thought "Anchoring" the html would be a good idea; but how do you apply that to a prefab website?

Collapse
 
tomasforsman profile image
Tomas Forsman

This is my personal take on user stories:

  • Business goal: We want users to log in
    • Problem/roadblock: Users log in more if they can do it fast and easy
    • User story: I want to log in with my social media credentials to avoid having to remember mail and password.
    • User story: I want to be able to log in with email and password so I don't have to be logged in with a social media account on the computer where I want to log in.

In the best of situations, this is something that has been worked out with all involved in a project. The project owner, customer, developers, UX, designers, testers, management, sales. If they are all part of the process of creating user stories they will all understand the most important aspect of the project, why it is done at all. This will help all the way from the first test being written to the launch and beyond. When the customer checks in, and he should, and sees that the UI is very bare and there are just a few strange tests in place, it's not uncommon that he panics and feel like there's nothing done yet, why have you wasted so much time on a few tests when you could have made those features and a couple of more in that time? With agreed upon user stories in place, things look different. The barebones UI is in place only to facilitate the tests since it will most likely be changed later. The customer can see, or at least after a quick explanation, that each test is done to secure that a user story is met. The user stories in this example illustrate the problem in a less abstract way. Tests are connected to user stories rather than the problem since it reminds everyone why they are done. The same goes for decisions in UX, they are connected to user stories since it is less abstract than connecting them to the problems they are supposed to solve.

User stories are simply illustrations of solutions to a problem. When all user stories are met the problem is overcome. When all problems are overcome the business goal is met. When all business goals are met the product is ready.

Collapse
 
redfred7 profile image
Fred Heath

Hey Tomas,

User stories are simply illustrations of solutions to a problem.

The thing is, there are plenty of people who say otherwise. They think stories are requirements, functionality, goals and many more. Now, if you, your colleagues and all of your stakeholders agree on your definition and read/write stories with your definition in mind, then that's great. Otherwise, I wish you good luck.

Collapse
 
jakubkeller profile image
Jakub Keller

You could spend all your time refining the perfect card and none actually developing. Write up a generic card. If you need more info, find the product owner, huddle with some devs. Work. Everything else nonsense. And look I wrote my article in a comment box!

Collapse
 
jakubkeller profile image
Jakub Keller

Does any of this really matter? Seriously.

Collapse
 
benhosk profile image
Ben Hosking

I think we should start with goals and capabilities so everyone knows the purpose of the functionality.

User stories should go into the details and remove the assumptions. clear acceptance criteria

Collapse
 
redfred7 profile image
Fred Heath

Pretty much agree Ben. We need to know what we're doing and why we're doing, before we decide how to do it. User Stories can help describe and clarify all of the above. But that's all they are: descriptors, properties, attributes. We need to start talking about the whats, whys and hows instead of their attributes.

Collapse
 
kr428 profile image
Kristian R.

Very much enjoyed reading the article. And at some point definitely agree with the idea we should get our language sorted. I'm experiencing exactly the same scenario as pointed out in the "Twitter" / social media example here, once in a while, when different stake holders argue about how broad or generic a given user story should be. For that example: Is "I want to be able to log in using Twitter credentials" an implementation detail? Is it a high level business "user story"? As far as I am concerned, it depends. It could be both, and both could be very well valid. Using the impact map approach could help getting such things sorted, but what helped in my environment pretty much in such situations is a slow and careful process of balancing different stakeholders and dev teams in order to find a "common ground" understanding of things, a shared level of abstraction that works reasonably well for most (best of course: all) people involved with the process.

Collapse
 
redfred7 profile image
Fred Heath

thanks for the feedback Kristian. IMO, "I want to be able to log in using Twitter credentials" sounds like it answers the question "What do I want to do with the system so I can achieve my Business Goal?" and is, therefore, a Capability.

However if the Business Goal is "Make system login easier so that I can attract more users", then you can say that the Capability is "able to log in using Social Account credentials" and "login with Twitter" answers the question "How do I deliver this capability?" i.e. a Feature

I find that the following help to distinguish a Capability from a Feature

Capability Feature
Granularity Coarse Fine
Key Action Enables Allows
Key Question What to do? How to do it?
POV An actor wants to do something System offers a functionality

It's all about putting things in the right context and Impact Mapping is ideal for this.

Collapse
 
pabrams profile image
Paul Abrams

What's your point exactly? User Stories are bad? I think they're pretty good for helping business folk understand what features they'll get. They can't think abstractly, they need User Stories. Your conclusion that a User Story is not a Feature is of course correct, but I didn't personally hear anyone claiming the contrary. I've always understood them as examples of a user's interaction with the system. If you understood them as something else until recently, that's unfortunate, but it doesn't necessarily mean they're bad. Anyway, your actual arguments seem to be more about the term User Story being misleading, in which case I also disagree. I think it's a pretty good description of what they are: a user's "story" about their interaction with the system to achieve some outcome. I'm not sure how you or anyone ever reached the conclusion that they were Features.