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
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
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.
- Our system Requirements are the Capabilities in the context of the beneficiary Stakeholders and valid Business Goals
- We can describe Capabilities and Business Goals with User Stories. This doesn't mean that the stories are these things.
- 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)
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)
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.
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...
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.
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?
This is my personal take on user stories:
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.
Hey Tomas,
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.
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!
Does any of this really matter? Seriously.
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
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.
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.
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
It's all about putting things in the right context and Impact Mapping is ideal for this.
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.
Technically, this is the user story:
"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 this is implementation details:
"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"
The user story is an analysis artifact, for use when such things are needed (the scope of that conversation is far to large to indulge in a blog comment). A user story is a shared artifact that has application and use to all stakeholders (of which developers are included).
The implementation details are still valuable and still needed, but not always necessary or applicable to all stakeholders.
The user story is the context and justification for proceeding with implementation details, but not the implementation details themselves.
The ambiguity that has gathered around the use and purpose of user stories is largely the result to encasing them in tooling - especially implementation tooling, like Gherkin, and the unbridled assumption by implementers that analysis artifacts require the benefit and blessing of developer tooling.
Developers do need to be thinking more about the implementation details, but it would be an over-stepping of bounds by developers to presume to interfere with or disable either upstream or downstream parts of a process that do not directly pertain to them.
Developers have a role in user story work, and the sooner their oversight is brought to bear, the sooner that mistakes can be avoided and unrealistic expectations can be addressed. But it should go without saying that the elaboration of details inherent to developers' work is largely impertinent to the initial ideation work that doesn't require (or isn't empowered by) implementation details.
Hey Scott,
This has nothing to do with tooling or with implementation details. If it did then we'd be talking about SAML tokens or doing the OAuth dance. What you're describing above as 'implementation details' is actually a system behaviour. Description of system behaviours is what is commonly known as a Functional Specification. We call a specific system behaviour a Feature. A set of Features is our Specification. Note that I haven't used the term 'user story' anywhere in this paragraph.
This article is all about communicating using well-defined and tightly-scoped terms, i.e. not user stories. It's also about bridging the gap between requirements and specifications using impact mapping.
HTH
What you are describing are use cases (use case documents and diagrams included). User stories are a step after the stakeholders and the developers signed off on the use case documents.
User stories are generally speaking just there for the developers. If a stakeholder is interested in a user story for some reason, you can show him the relevant use case document.
Hi Slava and thanks for the feedback.
Use Cases are also a good tool for mapping the Requirements into Specifications, I totally agree with that. However, Features and the Gherkin DSL provide a uniform syntax and a standardised way of verifying the Specifications, through a number of tools such as Cucumber, Specflow, etc. For that reason, I prefer using Features over Use Cases.
Awesome thought. I agree with this post except on the point of everyone do it this way. Best practices are a myth and if something is working and the team and its stakeholders all understand and get value out of their abstraction, definition and understanding of a user story, no one from outside can move them to change if they don't feel the pain you are solving. I like this as another tool in the bag, but rules are for breaking and are always open to interpretation and improvement.
Hi Charles. Yes indeed, I would never prescribe this (or anything else) as a panacea. It's just a good way I found of modelling and bridging Requirements to Specifications while avoiding getting lost in the whole 'user story' kerfufle.
Thank you for sharing this. I am inspired to delve deeper into getting rid of user stories in my own area of influence. I have long noticed a gap between what the customer wants versus the way a developer internalizes and plans the solution. This seems to be a bridge.
Thanks for the response Ernie. You're absolutely right. This bridges the Requirements with the Specifications.
Language is most important, to ensure clarity and avoid misunderstandings. This is true in any walk of life, not just software development. Get the language right and you stand a better chance of the end goal being reached. No disagreement there.
However, in the end, everything we as programmers do ends up as ones and zeroes. How we get there matters but so does what happens next. Development is only part of the life cycle of a product and too much focus on that part alone can adversely affect the rest.
No matter if you call them User Stories or Business Goals, Capabilities and Features, they all have to find their way into code somewhere, and there's a big problem that in too many cases, for anyone other than the original author there's no easy way to find where they went. Sure, the product got delivered on time and delivered everything that was asked of it, but over time these requirements tend to change significantly. New Government regulations, new product variants and un-anticipated problems of all kinds force changes to be made, and here it's not of primary importance what you agreed to call it but where in this huge pile of code to find it so you can change it without wrecking the whole thing.
In the world of databases they have a big advantage over other people. They have SQL and you know where you are with that. The rest of us have to struggle with a coding language that was designed to do everything and nothing in particular, in a framework that went obsolescent half a decade ago, trying to figure whether that weirdly-named function really does what it implies or if half of what you need is somewhere else completely.
So yes, let's talk about language and understanding, but let's recognize it as the thing that underpins everything we do, to the point that if we don't pay due attention to it we are inviting failures at every step along the way.
I agree with most of the above Graham. However, my post is not merely about about what to call something. It's about understanding what that 'something' is. With User Stories, we are referring to that 'something' 's description or narrative. But not that 'something' itself.
User Stories are a great post-analysis device. Once we have captured and modelled our Requirements, which can be expressed as User Stories themselves, then writing Stories are a great way to help us define our Specifications, i.e. our system behaviour, i.e. our Features.
But User Stories as an analytical abstraction offer no more value (and sometimes less) than a business process diagram or a set of examples. Which is why we need to be analysing & parsing a Story/diagram/example into its constituent domain entities (Goals, Capabilities, Features) and refer to them instead of their ancestral story/diagram/example.
When a client comes to me with a User Story, example, conversation, etc, I will analyse its impacts and create a model (Impact Map). From then on I will keep referring to those model entities and I will communicate this to my client. I will also create new User Stories as descriptions for any derived Features. The original stories/examples/conversation are only transient descriptors that helped create the model. Any new stories just help describe our model entities. It's those entities that we're basing our system on, not the stories behind them.
I don't think your clients are going to care about your Impact Maps. You can build the system based on whatever intermediate design artifacts you want, but I don't think you can expect your clients to understand them or want to talk about them. They see things in terms of User Stories, and if that makes them "first class requirement artifacts" in your opinion, then I think you're probably just going to have to deal with it.
Hi Paul,
The reason clients see things in terms of User Stories is because that's what we tell them. And the outcome is that clients (but often also developers, BAs and others) muddle up requirements, specifications, goals, technical tasks, etc under the 'User Story' umbrella. Tremendous confusion and lengthy backlogs ensue.
So let's stop talking about 'User Stories' and start talking about: