Many Agile purists will argue User Stories are NOT requirements; their contention is that User Stories are goal oriented, while Requirements decompose product scope. This is partly true. Functional Requirements tend to be descriptive of a solution; however, the actual Business Requirements should be goal oriented. Hence, a statement of business need. Having worked with many Application Developers during my career, I can understand their frustration. Most developers want to avoid being “boxed in” to a solution and want the flexibility to build solid applications. In many cases, a Business Analyst will step over the line and will begin recommending solutions which either won’t work, will be too complex to develop, or will take too much time to develop. User Stories are a way to keep non-technical folks from stepping over those boundaries. Whether you’re writing traditional BRD’s, or User Stories, understand these are two METHODS which seek to achieve the same results.
We are in the business of transforming human thought, into tangible “Products” (usually applications) that achieve a business goal or solve a business problem.
The utilization of Acceptance Criteria to ensure software (a product) meets stakeholder needs is very common. In the "Agile" realm (for all intents and purpose, SCRUM), Acceptance Criteria define the boundary of the User Story; basically, it's how we can tell if the story has been fulfilled and is working as intended. In terms of language, these criteria are lower level goals the User wishes to achieve, decomposed from the higher-level User Story. For BA's, it's very similar to the way higher level Business Requirements are decomposed into Functional and Non-Functional Requirements. In that model, we are clearly stating business needs and describing the solution(s) in more and more detail.
In Agile, these Acceptance Criteria are then transformed into Test Cases; this ensures we have a Pass/Fail verdict for each criterion (and ensures that we have traceability). The idea of using a Pass/Fail method for testing quality infers Acceptance Criteria are objective. For the most part, this is true.
However, there is a major exception to this rule. User Experience. With UX, we are talking about the User’s subjective experience interacting with the web site or application. This is not to be confused with Usability, which has a narrower focus ensuring a “product” enables the User to complete a set of tasks. This means we are dealing with the User’s attitudes and opinions of the product we are delivering, not just whether it works as specified.
As many of us who have worked in custom application development for any length of time understands that this poses a challenge with regards to measuring success. We can use a variety of techniques to gain insight into a User groups’ satisfaction with our product. We can even have a fairly good idea as to their likes and dislikes. However, we must understand this is not a hard science, but can have a tremendous influence on our success.
A great example from about 10 years ago was the launch of the iPhone. Apple introduced a product which would completely revolutionize how the world communicates. This wasn't by done by accident. What set Apple apart wasn't just the functionality, it was the User Experience. From the slick packaging and presentation of a brand-new iPhone, to the building of anticipation of every release – Apple created a brand-new segment of the cell phone market which it would dominate for years to come – the smart phone.
Over the years, many competitors have attempted to replicate this success. The devices have become increasingly sophisticated, with an astonishing amount of functionality packed into a small unit. While the competition could match the physical qualities of the iPhone, most were unable to match Apple’s success. Do you remember the Blackberry Storm? I don’t either.
So, what does this all mean? The most important implication of this example is that it is NOT enough to focus on objective measures of success. Fulfilling a User Story and passing Acceptance Criteria is simply a starting point, the attitudes and interest of your Users may be even more important. It’s not just what your Users can and want to do, it’s how they feel about what they’re doing. Their attitudes and opinions can ultimately make or break your project, so it’s very wise to pay attention.