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.
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 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.
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).
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:
What we're doing (Capabilities)
Why we're doing it (Business Goals)
How we're doing it (Features)
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.
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: