"As an end-user
I want to log-in with my social media credentials
so I don't have to remember extra usernames and passwords"
And this is implementation details:
"As a end-user with a Twitter account
I want to log-in with my Twitter credentials
so I don't have to know extra usernames and passwords"
The user story is an analysis artifact, for use when such things are needed (the scope of that conversation is far to large to indulge in a blog comment). A user story is a shared artifact that has application and use to all stakeholders (of which developers are included).
The implementation details are still valuable and still needed, but not always necessary or applicable to all stakeholders.
The user story is the context and justification for proceeding with implementation details, but not the implementation details themselves.
The ambiguity that has gathered around the use and purpose of user stories is largely the result to encasing them in tooling - especially implementation tooling, like Gherkin, and the unbridled assumption by implementers that analysis artifacts require the benefit and blessing of developer tooling.
Developers do need to be thinking more about the implementation details, but it would be an over-stepping of bounds by developers to presume to interfere with or disable either upstream or downstream parts of a process that do not directly pertain to them.
Developers have a role in user story work, and the sooner their oversight is brought to bear, the sooner that mistakes can be avoided and unrealistic expectations can be addressed. But it should go without saying that the elaboration of details inherent to developers' work is largely impertinent to the initial ideation work that doesn't require (or isn't empowered by) implementation details.
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).
This has nothing to do with tooling or with implementation details. If it did then we'd be talking about SAML tokens or doing the OAuth dance. What you're describing above as 'implementation details' is actually a system behaviour. Description of system behaviours is what is commonly known as a Functional Specification. We call a specific system behaviour a Feature. A set of Features is our Specification. Note that I haven't used the term 'user story' anywhere in this paragraph.
This article is all about communicating using well-defined and tightly-scoped terms, i.e. not user stories. It's also about bridging the gap between requirements and specifications using impact mapping.
HTH
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.
Technically, this is the user story:
"As an end-user
I want to log-in with my social media credentials
so I don't have to remember extra usernames and passwords"
And this is implementation details:
"As a end-user with a Twitter account
I want to log-in with my Twitter credentials
so I don't have to know extra usernames and passwords"
The user story is an analysis artifact, for use when such things are needed (the scope of that conversation is far to large to indulge in a blog comment). A user story is a shared artifact that has application and use to all stakeholders (of which developers are included).
The implementation details are still valuable and still needed, but not always necessary or applicable to all stakeholders.
The user story is the context and justification for proceeding with implementation details, but not the implementation details themselves.
The ambiguity that has gathered around the use and purpose of user stories is largely the result to encasing them in tooling - especially implementation tooling, like Gherkin, and the unbridled assumption by implementers that analysis artifacts require the benefit and blessing of developer tooling.
Developers do need to be thinking more about the implementation details, but it would be an over-stepping of bounds by developers to presume to interfere with or disable either upstream or downstream parts of a process that do not directly pertain to them.
Developers have a role in user story work, and the sooner their oversight is brought to bear, the sooner that mistakes can be avoided and unrealistic expectations can be addressed. But it should go without saying that the elaboration of details inherent to developers' work is largely impertinent to the initial ideation work that doesn't require (or isn't empowered by) implementation details.
Hey Scott,
This has nothing to do with tooling or with implementation details. If it did then we'd be talking about SAML tokens or doing the OAuth dance. What you're describing above as 'implementation details' is actually a system behaviour. Description of system behaviours is what is commonly known as a Functional Specification. We call a specific system behaviour a Feature. A set of Features is our Specification. Note that I haven't used the term 'user story' anywhere in this paragraph.
This article is all about communicating using well-defined and tightly-scoped terms, i.e. not user stories. It's also about bridging the gap between requirements and specifications using impact mapping.
HTH