Are agile user story acceptance criteria the same as traditional functional requirements?

Question

Let's take a traditional functional requirement:

The system shall allow the user to create an account with an email address and password

A user story that covers this requirement might be:

As a shopper I want to create an account so that my preferences will be retained

And the acceptance criteria for this story might look like:

If I am a shopper I can create an account by submitting an email address and password

The functional requirement is very similar to the acceptance criteria. And I can think of no examples of functional requirements, that wouldn't translate directly to acceptance criteria for the story that implements it.

Answer 1

I don't think that there's a 1-1 mapping between functional requirements and user stories or acceptance criteria.

First, your example of a functional requirement isn't a good requirement. It's not atomic - I would write your functional requirement as multiple requirements:

• The system shall require an email address to create an account.
• The system shall require a password to create an account.

I would then add additional requirements to address uniqueness of email addresses, any kind of password requirements, and perhaps even validation of email addresses. In the end, I would have around 5 or 6 traditional "shall" statements relating to the users creating an account.

As you can tell, there's nothing in these requirements about storing preferences, which is a key aspect of your user story. Looking at your acceptance criteria, you have design decisions codified that aren't part of the user story. There's a disconnect there.

In an agile project that uses user stories, I would create an epic for user accounts and profiles. One story under this account would be creating an account: "As a shopper, I want to create an account with an email address." You may have other stories about logging in with Google or Facebook (or some other SSO) that are part of this epic. Your acceptance criteria would be created to define cases: What should happen when the same email address is used twice? What should happen if a user enters the wrong email address? What happens if something that isn't a valid email address isn't entered?

I would recommend not trying to map concepts from traditional project management methods to agile methods. You tend to do the same types of things, but there isn't a clean 1:1 mapping between things.

Answer 2

Functional requirements require people to be able to think abstractly about the problem. Specifications written this way tend to be very dense and have many implications. Often people writing these get confused between requirements and implementation.

User stories don't require as much abstraction. They also force the person writing them to think about how the software is used, and less in how it is implemented.