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