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.
Fred is a software jack of all trades, having worked over the last 24 years at every stage of the SDLC and has authored [two books](https://www.amazon.co.uk/Fred-Heath/e/B08F3Q1H1M).
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.
Fred is a software jack of all trades, having worked over the last 24 years at every stage of the SDLC and has authored [two books](https://www.amazon.co.uk/Fred-Heath/e/B08F3Q1H1M).
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.
Fred is a software jack of all trades, having worked over the last 24 years at every stage of the SDLC and has authored [two books](https://www.amazon.co.uk/Fred-Heath/e/B08F3Q1H1M).
And who ever said User Stories were "first-class entities in the Requirements Domain", anyway?
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.
I've only ever understood or used them as tools to help communicate requirements
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.