loading...

re: Enough with the User Stories already! VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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 m...
 

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

code of conduct - report abuse