User stories and Acceptance Criteria for Configuration System

Not all work benefits from the model of user stories.  In fact, user stories are not mentioned anywhere in the Scrum Guide.  All that the Scrum Guide mentions are Product Backlog items.  They are explained like this:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

You might not need to use the Scrum framework.  In the Guide a definition of Scrum is provided.  Here is part of that definition.  

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat

If your team is doing configuration work, you might not gain any benefit from the Scrum framework as that work is usually not overly complex.  

Can you please advise best practice on how to create user stories and acceptance criteria for configuration changes (similar to Salesforce)? What level of detail is needed?

A user story is a placeholder for a conversation about a potential requirement. So never mind about how much detail is "needed". How much detail about these configuration changes exists, which has been validated, and which the team are already quite sure of? If the risk of misconfiguration is low, and they know what to do, why use Scrum or user stories in the first place? 

Thanks for the responses. When a customer requests a feature, about 50% of requests can be satisfied through configuration, 50% requires either custom software development or a core change to the software product. We are trying to get consistent with our approach to requirements by writing user stories for all requests, irrespective of how the solution will be implemented. It is also important that configuration changes can be tested. 

When a customer requests a feature, about 50% of requests can be satisfied through configuration, 50% requires either custom software development or a core change to the software product. We are trying to get consistent with our approach to requirements by writing user stories for all requests, irrespective of how the solution will be implemented. It is also important that configuration changes can be tested. 

This doesn't make sense to me.

User stories originated from Extreme Programming, one of the methodologies that led to Agile Software Development. The reason that Agile Software Development is so successful is that it takes advantage of the characteristics of working in the complicated and complex domains, mostly involving the high number of unknowns in the project. User stories are a technique that was a developed to capture the need for functionality, defer the details until closer to when they were needed and to get those details from conversations with stakeholders to allow the real requirements to emerge. This also takes advantage of the fact that continuously evolving a product and putting minor changes in front of stakeholders also leads to changes in what is desired - stakeholders often don't know up-front exactly what is necessary, so large sets of specifications aren't very useful when large portions are later determined to be unnecessary.

Because the Agile methods are designed to deal with unknowns and uncertainty, they don't do well in the clear or obvious domain. In my experience, configuration of tools tends to be closer to the clear or obvious domain, sometimes entering into the complicated domain. Rarely is configuration in the complex domain. The highly iterative and incremental approaches of the Agile methods tend to add more overhead than the value that you get from being more responsive.

I wouldn't try to force configuration and development requests into the same workflow or format. They are inherently different types of work and should be treated differently. It even sounds like they are handled by two different teams, with configuration handled by a professional services organization and development handled by a product development organization. Letting each organization figure out the best ways of working for themselves would be far more in line with the spirit of lean and agile methods.

Nothing you have said seems to indicate that you are using the Scrum framework.  You are trying to use User Stories as a way of managing your requirements in your process.  With that being the case, there is nothing that anyone can say to say that you are wrong.  How you choose to implement requirement gathering in whatever process you use is entirely up to you.

I am assuming that you posted here because you did a search on "how to write user stories" or something similar and that search returned a few postings from these forums.  But user stories are not part of Scrum although they are widely used.  Since the Scrum framework says nothing about User Stories, every group that uses them decides how they are best able to help.  

So while I won't tell you how to use User Stories, I will suggest that you do not overly complicate your process just to say that you are consistent.  Often consistency adds overhead that lowers productivity.  Do what is right for the situation at hand with a goal of being able to adapt to changes quickly and as necessary.