Skip to main content
Project Management

Return to Question

clarification
Source Link
RaymondB
RaymondB
  • 51
  • 2

My organization has been leveraging SAFe for a few years now and as a Team lead I am concerned about the sort of Feature Acceptance Criteria being defined. Specifically its extremely vague and I would hope that SAFe or even Agile would have some guidelines around 'good' AC on a feature.

I see the SMART acronym thrown around a lot ( Specific, Measurable, Achievable, Realistic, and Timely) and that's an example of a guideline I was thinking of.

By way of example, my current feature has an AC: 'Verify the put API updates correct information in DB' Imho that's too loosely defined (what is 'correct'?) to be valuable to us.

since terminology may be slightly different: the 'feature' I am referring too is the work that a dev team gets assigned at the Quarterly planning where the team tries to break it down into stories.

Somewhat related: if a dev team encounters a scenario during Increment Planning where it is not comfortable that the feature is fully understood, what are the recommended ways to raise those concerns? We have been raising Risks thus far but since those get 'accepted' its not really leading to meaningful improvement in the feature definition process.

Any SAFe experts want to guide me? thanks

Edit: several responders have pointed to guidance around User Stories - this is NOT what I am referring to. In SAFe, a feature is a higher level artifact that a dev team breaks down into user stories. my question relates to the Feature artifact.

My organization has been leveraging SAFe for a few years now and as a Team lead I am concerned about the sort of Feature Acceptance Criteria being defined. Specifically its extremely vague and I would hope that SAFe or even Agile would have some guidelines around 'good' AC on a feature.

I see the SMART acronym thrown around a lot ( Specific, Measurable, Achievable, Realistic, and Timely) and that's an example of a guideline I was thinking of.

By way of example, my current feature has an AC: 'Verify the put API updates correct information in DB' Imho that's too loosely defined (what is 'correct'?) to be valuable to us.

since terminology may be slightly different: the 'feature' I am referring too is the work that a dev team gets assigned at the Quarterly planning where the team tries to break it down into stories.

Somewhat related: if a dev team encounters a scenario during Increment Planning where it is not comfortable that the feature is fully understood, what are the recommended ways to raise those concerns? We have been raising Risks thus far but since those get 'accepted' its not really leading to meaningful improvement in the feature definition process.

Any SAFe experts want to guide me? thanks

My organization has been leveraging SAFe for a few years now and as a Team lead I am concerned about the sort of Feature Acceptance Criteria being defined. Specifically its extremely vague and I would hope that SAFe or even Agile would have some guidelines around 'good' AC on a feature.

I see the SMART acronym thrown around a lot ( Specific, Measurable, Achievable, Realistic, and Timely) and that's an example of a guideline I was thinking of.

By way of example, my current feature has an AC: 'Verify the put API updates correct information in DB' Imho that's too loosely defined (what is 'correct'?) to be valuable to us.

since terminology may be slightly different: the 'feature' I am referring too is the work that a dev team gets assigned at the Quarterly planning where the team tries to break it down into stories.

Somewhat related: if a dev team encounters a scenario during Increment Planning where it is not comfortable that the feature is fully understood, what are the recommended ways to raise those concerns? We have been raising Risks thus far but since those get 'accepted' its not really leading to meaningful improvement in the feature definition process.

Any SAFe experts want to guide me? thanks

Edit: several responders have pointed to guidance around User Stories - this is NOT what I am referring to. In SAFe, a feature is a higher level artifact that a dev team breaks down into user stories. my question relates to the Feature artifact.

Tweeted twitter.com/StackProjects/status/1292249304695005184
Source Link
RaymondB
RaymondB
  • 51
  • 2

In SAFe (Scaled Agile Framework); are there any guidelines around what feature acceptance criteria should look like (eg SMART)?

My organization has been leveraging SAFe for a few years now and as a Team lead I am concerned about the sort of Feature Acceptance Criteria being defined. Specifically its extremely vague and I would hope that SAFe or even Agile would have some guidelines around 'good' AC on a feature.

I see the SMART acronym thrown around a lot ( Specific, Measurable, Achievable, Realistic, and Timely) and that's an example of a guideline I was thinking of.

By way of example, my current feature has an AC: 'Verify the put API updates correct information in DB' Imho that's too loosely defined (what is 'correct'?) to be valuable to us.

since terminology may be slightly different: the 'feature' I am referring too is the work that a dev team gets assigned at the Quarterly planning where the team tries to break it down into stories.

Somewhat related: if a dev team encounters a scenario during Increment Planning where it is not comfortable that the feature is fully understood, what are the recommended ways to raise those concerns? We have been raising Risks thus far but since those get 'accepted' its not really leading to meaningful improvement in the feature definition process.

Any SAFe experts want to guide me? thanks