5

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.

2

I can't really answer this from a SAFe perspective since I'm not very familiar with the framework, but I'll add a general answer nonetheless because I sense some confusion in the way the question was asked (and it's too big for a comment :)).

For example, the "Verify the put API updates correct information in DB" AC that you mention, isn't really an AC. An acceptance criteria is a behavior the application should have or a thing that it should do from the perspective of the product owner/user/client. What does the "put API" do? When you call it what's the expected result? What should happen? What's the new context inside the application? Etc.

User stories, for example, are described by 3Cs: Card, Conversation, Confirmation. In the Confirmation part you have acceptance criteria that gives you the things to look at to ensure that the story is implemented correctly and all requirements are met. A proper AC should be something like "When a product is updated, then the change is consistent across all product pages", or whatever the "put API" does. It's not "the API updates correct information in the DB". It's obvious that the information should be correct in the DB, otherwise your AC can be expanded to say "the new code we've written should have no bugs that cause DB inconsistencies" which isn't very useful. It's a matter of common sense that the developers need to know what they are doing technically. The AC is for them to know that they are building "the right thing" functionally. They can update the DB just fine when building the wrong thing too.

The ACs are agreed upon when discussing the feature and breaking it into stories. It's part of the second C, the conversation everyone needs to have in order to understand what needs to be built. To put it bluntly, it's like asking your product owner "Hey Product Owner, after we build this thing, what will you look at to see if it's the right thing? What will you check? How will you confirm that this is what you wanted?".

Based on the conversations, you will then split the feature into stories with ACs on them, or even find some ACs that can stand alone and become stories themselves. You will have ACs on the stories that make up the feature, and maybe some larger ACs on the feature itself too, if the combined ACs on stories don't cover everything. Even if you define ACs at the feature level, the way you do so is by having a conversation and decide on the things that can give you the Confirmation that you built the right thing.

If you are creating an API that allows for CRUD of specific data, and the only way to confirm the feature does the right thing is by looking inside the DB, then that's what you have to do. Bbut be aware, that as I mentioned above, you should consider behavior of the application. For example, your AC might say "the data is updated in the DB correctly", but if there are application caches for example that also need to be invalidated after the update, your AC on the CRUD feature won't give you a Confirmation that the application does what's needed with the new feature in it.

Once you figure out what AC you will look for, you can take things a step further and try to automate some of the ACs with Acceptance Test–Driven Development (ATDD).

As for your last question:

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?

This is part of the second C, the conversation. You should not start implementing a solution until everyone involved understands what needs to be built.

| improve this answer | |
  • 1
    The second C almost can't be over-emphasized. Communication with the client and/or product owner is necessary to gain a reliable understanding of what the software should do, and taking shortcuts here because you feel you know what's needed or the client isn't interested in communication will often cause wasted resources and missed schedules. This doesn't mean all communication must happen up-front, it's perfectly fine to get to a common agreement that some aspect isn't fully understood yet and needs to be clarified by building a prototype, for example. – Hans-Martin Mosner Aug 9 at 11:34
  • totally appreciate the comprehensive response and those links. It appears you are referring to the story AC. in Safe, the feature is a higher level artifact which represents multiple sprints of work. feature are broken down by the dev team into smaller stories that can be completed within a sprint. As dev team Lead I collaborate with my team and Product Owner to build those AC and I am complete on board with that. the overall feature is more representative of a capability, in this case its to create an API that allows for create, read and update of specific data – RaymondB Aug 9 at 15:33
  • I understand what a feature is. You can have ACs on the stories that make up the feature, and maybe some larger ACs on the feature itself too, if the combined ACs on stories don't cover everything, but what I said still stands. You need to sit down with everyone and build understanding on what the feature should do. As part of that conversation you look for ways to confirm that you built the correct thing, and by figuring out how you get that confirmation is the way you get your list of ACs. – Bogdan Aug 9 at 16:35
1

According to SAFe:

Product Management is responsible for accepting the features. They use acceptance criteria to determine whether the functionality is properly implemented and nonfunctional requirements met.

Acceptance criteria can also be used as the source of stories. As with stories, acceptance criteria are often transformed into acceptance tests with Behavior-Driven Development (BDD).

We should write feature acceptance criterias with that in mind. And we could also write in such a way that it is possible to transform them in user stories later. In that case, they should have the information necessary to form the GWT (Given-When-Then) format.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.