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