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!
Top comments (44)
I might be alone in thinking this, but I think userstories should be broad and abstract. The userstory "As an enduser I want to login with social media accounts"
Is a perfectly written userstory in my opinion.
If a developer dont know how to implement it becouse it is to abstract, that developer is at the wrong place of work.
Ofcourse the first implementation wont be perfect, but that is the reason you have short sprints.
I disagree. Refinement is the usual scrum process in which devs make abstract stuff less abstract together with product owners and/or stakeholders.
If you keep it abstract, the chances are pretty high you're building things people didn't ask for. Non technical users often hear technical terms and want to use jargon in sentences even though they have no idea what they're talking about — part of the devs job is to clarify vague tasks by interrogating the person who requested the feature.
Maybe I have a different view but I don't quite agree with you :(
"part of the devs job is to clarify vague tasks by interrogating the person who requested the feature" - that is not rly true.
The project owner talks to the customer and understands what the customer want.
The Project owner divides the tasks up, here (in my opinion) the project owner creates broad abstract tasks for the devteam, the devteam pick apart the tasks and creates subtasks that they can use in a sprint.
Now if the customer had very specific request: "the log in with twitter page needs to be blue". The project owner might either add that in the user story (making it less abstract) or (what I would like) tells the customer that the UX team will decide how the page should look because they have studied years in how to do that, and the customer, as a general rule, have no idea what they are talking about.
I just think its weird that the developer more and more seems to get the role of the project owner, and more and more the project owner seems to be someone with less and less programing skills (in my experience).
Fully agree with you on that.
What I mean was: It's not the task of the developer to "know what to build out of experience", if there is any ambiguity they should indeed throw it back to the product owner.
A developer should get some clarity on technical/implementation details by refining together with the product owner, but when the user story itself is still too vague it's indeed not the dev's job.
Ah okay, I'm sorry maybe I didn't fully understand you before, thanks for clarifying. :)
Can the three C's and I.N.V.E.S.T. help the situation? if "yes", how? And if "no", why?
The I.N.V.E.S.T. technique is about scoping and structuring user stories. It is useful as a guideline for non-technical stakeholders who create user stories. But it doesn't help differentiate user stories from their constituent model entities. So no, I.N.V.E.S.T. doesn't help our situation.
3Cs advocates conversations and the use of acceptance criteria. This is useful when discovering Features and Scenarios, i.e. acceptance criteria. So, yes, the 3Cs are useful when analysing an incoming requirement but we still need more than that in order to contextualise the requirement and translate it into specifications (Goal -> Capability -> Features)
The point of stories isn’t to tell developers how to implement things, it’s to protect developers from being blamed when a requirement is communicated poorly and to protect the company by not driving all of their developers away because they’re pissed off at dealing with pass-the-buck politics.
Hi @tomd-chalmers. The thing is, user stories can be used to describe anything. As the description of a requirement / business goal / high-level capability then, I agree, this story is perfect. As the description of a specific system behaviour, i.e. a specification, then this story is useless.
So we need to parse and analyse this story and decide what it represents in terms or our Domain Model entities. In order to do that, I use a set of techniques I call D3 (Decomposition -> Derivation -> Discovery ) but that's for another blog post.
Point is, we need to stop talking about user stories as separate entities or this confusion and ambiguity will continue. Let's start talking about Business Goals, Capabilities, Features and Tasks instead.
There's a difference between generic and abstract. In this case the user story is written very generic, not abstract.
A user stories can be generic as this will solicit talking to the customers, users, stakeholders or business-representatives like marketing, sales, etc. The user story can be a start of a conversation, that's the main reason user stories can be vague and generic.
If there's no way for developers to properly communicate with any of those people user stories, and scrum in general isn't not the methodology you should use.
I don't mean to be a pedant but your gherkin scenarios should really be in a "given, when, then" format so that they follow the "arrange, act, assert" pattern. Also I would say that the feature/user story differs from gherkin scenarios in 1 fundamental way in that a user story or feature description is an explanation of WHAT the software should do whereas the scenarios and the steps are a description of HOW the software should behave, so I actually think they are both needed for different levels of abstraction
Thanks for the feedback @petergsimons . Yes, the 'Given' step has been replaced by 'When' due to bad pasting and I will change that, thanks for spotting it :)
As to your 2nd point, my assertion is simply that the Feature is a response to the question "How does the system need to behave in order to deliver a specific Capability?", i.e. a Feature describes behaviour. We outline that behaviour with a User Story or just plain prose. A User Story is just a generic description of the behaviour, in this I think we agree. My point is that a User Story is not the Feature. The Feature is the Feature. A Feature is an entity with many attributes, one of which is its description. The value of that attribute may be a User Story. Or it may not.
We then use Scenarios to examine this behaviour from different perspectives and in different contexts. A Scenario is still the same behaviour but viewed from different angles, a bit like turning a Rubik's cube in your hand and looking at its different sides. We are still describing the same cube but from different angles.
Hope this makes it clearer.
I find this post rather confusing. In all companies I've worked for user stories are used to communicate the stakeholders / pos wishes towards devs, not the other way around.
Hi @ppeterman. This kind of illustrates the point I'm making. Because user stories are used to describe almost anything (wishes, business goals, generic capabilities, etc), talking about user stories is utterly confusing.
Requirements (i.e. wishes, needs and desires) come in all shapes, forms and sizes, of which the use-story format is but a minority. Many requirements are communicated by the stakeholders in examples, diagrams, simple text or verbal conversations.
It's our job as s/w engineers, analysts, etc to parse these Requirements and map them into Specifications, i.e. well-defined system behaviour. We can leverage User Stories to describe this behaviour or we can use some other descriptive device. The main thing here is that we delineate Requirement entities (Goals and Capabilities) from Specifications (Features)
So if your stakeholders are giving you User Stories, you still have to translate them into Requirements and Specifications. Writing Specifications (Features) is our job, not the Stakeholders'. If you start thinking in terms of Goals, Capabilities and Features then all the confusion will just dissipate :)
I think the problem that people are having is that they're not BAs or Product owners so they don't understand that you're talking about the requirements gathering aspect specifically and instead are confused as to why they think that you are trying to replace user stories, which you aren't.
Although that makes your title rather confusing
hey Justin, thanks for the feedback.
I don't think the title is confusing, I advocate stopping referring to User Stories as first-class entities in the Requirements Domain when they are just descriptive devices, so 'enough with the user stories' captures this sentiment :)
As to your first point, readers shouldn't be BAs or POs in order to understand the difference between Requirements and Specifications, or to know what a domain model is, or to grok the difference between an entity and an attribute. I dare think that most developers in this day and age are involved throughout the project lifecycle, so managing requirements is IMO an essential skill.
When you say "Enough with the user stories" it sounds like you're saying we should get rid of them completely, so it seems like a pretty confusing title to me, too.
And who ever said User Stories were "first-class entities in the Requirements Domain", anyway? I've only ever understood or used them as tools to help communicate requirements. Business people (often subject matter experts, and not real BAs) put a lot of emphasis on them, because those are usually the only artifacts they understand.
Hi Paul and thanks for responding
Whenever we talk about creating, reading and delivering user stories we are implicitly accepting them as first-class entities in the Requirements Domain, instead of just descriptors.
That they are. But they are also used to communicate specifications, business goals, capabilities and technical tasks. So let's start referring to these entities instead of their associated user stories.
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.
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:
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.
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'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.