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.
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: