I might be alone in thinking this, but I think userstories should be broad and abstract. The userstory "As an enduser I want to login with social media accounts"
Is a perfectly written userstory in my opinion.
If a developer dont know how to implement it becouse it is to abstract, that developer is at the wrong place of work.
Ofcourse the first implementation wont be perfect, but that is the reason you have short sprints.
I disagree. Refinement is the usual scrum process in which devs make abstract stuff less abstract together with product owners and/or stakeholders.
If you keep it abstract, the chances are pretty high you're building things people didn't ask for. Non technical users often hear technical terms and want to use jargon in sentences even though they have no idea what they're talking about — part of the devs job is to clarify vague tasks by interrogating the person who requested the feature.
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 I.N.V.E.S.T. technique is about scoping and structuring user stories. It is useful as a guideline for non-technical stakeholders who create user stories. But it doesn't help differentiate user stories from their constituent model entities. So no, I.N.V.E.S.T. doesn't help our situation.
3Cs advocates conversations and the use of acceptance criteria. This is useful when discovering Features and Scenarios, i.e. acceptance criteria. So, yes, the 3Cs are useful when analysing an incoming requirement but we still need more than that in order to contextualise the requirement and translate it into specifications (Goal -> Capability -> Features)
Maybe I have a different view but I don't quite agree with you :(
"part of the devs job is to clarify vague tasks by interrogating the person who requested the feature" - that is not rly true.
The project owner talks to the customer and understands what the customer want.
The Project owner divides the tasks up, here (in my opinion) the project owner creates broad abstract tasks for the devteam, the devteam pick apart the tasks and creates subtasks that they can use in a sprint.
Now if the customer had very specific request: "the log in with twitter page needs to be blue". The project owner might either add that in the user story (making it less abstract) or (what I would like) tells the customer that the UX team will decide how the page should look because they have studied years in how to do that, and the customer, as a general rule, have no idea what they are talking about.
I just think its weird that the developer more and more seems to get the role of the project owner, and more and more the project owner seems to be someone with less and less programing skills (in my experience).
What I mean was: It's not the task of the developer to "know what to build out of experience", if there is any ambiguity they should indeed throw it back to the product owner.
A developer should get some clarity on technical/implementation details by refining together with the product owner, but when the user story itself is still too vague it's indeed not the dev's job.
The point of stories isn’t to tell developers how to implement things, it’s to protect developers from being blamed when a requirement is communicated poorly and to protect the company by not driving all of their developers away because they’re pissed off at dealing with pass-the-buck politics.
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.
There's a difference between generic and abstract. In this case the user story is written very generic, not abstract.
A user stories can be generic as this will solicit talking to the customers, users, stakeholders or business-representatives like marketing, sales, etc. The user story can be a start of a conversation, that's the main reason user stories can be vague and generic.
If there's no way for developers to properly communicate with any of those people user stories, and scrum in general isn't not the methodology you should use.
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 might be alone in thinking this, but I think userstories should be broad and abstract. The userstory "As an enduser I want to login with social media accounts"
Is a perfectly written userstory in my opinion.
If a developer dont know how to implement it becouse it is to abstract, that developer is at the wrong place of work.
Ofcourse the first implementation wont be perfect, but that is the reason you have short sprints.
I disagree. Refinement is the usual scrum process in which devs make abstract stuff less abstract together with product owners and/or stakeholders.
If you keep it abstract, the chances are pretty high you're building things people didn't ask for. Non technical users often hear technical terms and want to use jargon in sentences even though they have no idea what they're talking about — part of the devs job is to clarify vague tasks by interrogating the person who requested the feature.
Can the three C's and I.N.V.E.S.T. help the situation? if "yes", how? And if "no", why?
The I.N.V.E.S.T. technique is about scoping and structuring user stories. It is useful as a guideline for non-technical stakeholders who create user stories. But it doesn't help differentiate user stories from their constituent model entities. So no, I.N.V.E.S.T. doesn't help our situation.
3Cs advocates conversations and the use of acceptance criteria. This is useful when discovering Features and Scenarios, i.e. acceptance criteria. So, yes, the 3Cs are useful when analysing an incoming requirement but we still need more than that in order to contextualise the requirement and translate it into specifications (Goal -> Capability -> Features)
Maybe I have a different view but I don't quite agree with you :(
"part of the devs job is to clarify vague tasks by interrogating the person who requested the feature" - that is not rly true.
The project owner talks to the customer and understands what the customer want.
The Project owner divides the tasks up, here (in my opinion) the project owner creates broad abstract tasks for the devteam, the devteam pick apart the tasks and creates subtasks that they can use in a sprint.
Now if the customer had very specific request: "the log in with twitter page needs to be blue". The project owner might either add that in the user story (making it less abstract) or (what I would like) tells the customer that the UX team will decide how the page should look because they have studied years in how to do that, and the customer, as a general rule, have no idea what they are talking about.
I just think its weird that the developer more and more seems to get the role of the project owner, and more and more the project owner seems to be someone with less and less programing skills (in my experience).
Fully agree with you on that.
What I mean was: It's not the task of the developer to "know what to build out of experience", if there is any ambiguity they should indeed throw it back to the product owner.
A developer should get some clarity on technical/implementation details by refining together with the product owner, but when the user story itself is still too vague it's indeed not the dev's job.
Ah okay, I'm sorry maybe I didn't fully understand you before, thanks for clarifying. :)
The point of stories isn’t to tell developers how to implement things, it’s to protect developers from being blamed when a requirement is communicated poorly and to protect the company by not driving all of their developers away because they’re pissed off at dealing with pass-the-buck politics.
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.
There's a difference between generic and abstract. In this case the user story is written very generic, not abstract.
A user stories can be generic as this will solicit talking to the customers, users, stakeholders or business-representatives like marketing, sales, etc. The user story can be a start of a conversation, that's the main reason user stories can be vague and generic.
If there's no way for developers to properly communicate with any of those people user stories, and scrum in general isn't not the methodology you should use.