loading...

re: Enough with the User Stories already! VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Hi @ppeterman. This kind of illustrates the point I'm making. Because user stories are used to describe almost anything (wishes, business goals, ge...
 

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

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.

Code of Conduct Report abuse