Do I Have a Story For You?
User Stories can (and should) completely replace Business Requirements on all projects
After almost 40 years of believing in the value of good Business Requirements, I am really beginning to understand what User Stories have to offer. It certainly could be argued that it’s taken me a really long time to get to this place, but perhaps I can partly rationalize this due to my observations of how unhelpful User Stories were in some of the early “Agile” efforts I was involved with. All of these early User Story efforts included very junior analysts and developers who seemed to have no idea what User Stories were supposed to be used for, and of course had no idea how to do anything other than copy User Story examples and try to modify them to apply to the current project they were on.
To BRD or Not to BRD
Mike Cohn’s well known book on User Stories (User Stories Applied, Copyright © 2004 by Pearson Education, Inc.) is not exactly the newest book on the fundamental concepts behind using User Stories for software application development, but I do believe it is was one of the best introductions to the topic, especially for those of us steeped in a background of structured requirements development.
After all of these years of being an evangelist of good requirements, I never thought I would seriously question my allegiance to having solid requirements — at least solid Business Requirements — for every single project. How else did we know what we were going to deliver?
But think about the last Business Requirements Document (BRD) that you wrote. Did you obtain full agreement and alignment with all the key stakeholders on all the requirements in this document? If you did, it was probably a painful path to get there. If it was a substantial BRD, I’d wager that not many of your key stakeholders thoroughly read and understood what they were signing off on.
Cohn depicts what happens with BRD’s quite convincingly:
The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications (IEEE 1998). This document, known as IEEE Standard 830, was last revised in 1998. The IEEE recommendations cover such topics as how to organize the requirements specification document, the role of prototyping, and the characteristics of good requirements. The most distinguishing characteristic of an IEEE 830-style software requirements specification is the use of the phrase “The system shall…”…. A typical fragment of an IEEE 830 specification looks similar to the following:
4.6) The system shall allow a company to pay for a job posting with a credit card. 4.6.1) The system shall accept Visa, MasterCard and American Express cards. 4.6.2) The system shall charge the credit card before the job posting is placed on the site. 4.6.3) The system shall give the user a unique confirmation number.
Documenting a system’s requirements to this level is tedious, error-prone, and very time-consuming. Additionally, a requirements document written in this way is, quite frankly, boring to read. Just because something is boring to read is not sufficient reason to abandon it as a technique. However, if you’re dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it is not going to be thoroughly read by everyone who needs to read it.
Cohn also points out that the interpretation of requirements can also be a difficult proposition:
Until trying it, it would seem simple enough to write down a bunch of software requirements and have a team of developers build exactly what you want. However, if we have trouble writing a lunch menu with sufficient precision, think how hard it must be to write software requirements. At lunch the other day my menu read: Entrée comes with choice of soup or salad and bread…. That should not have been a difficult sentence to understand but it was. Which of these did it mean I could choose?
Soup or (Salad and Bread)
(Soup or Salad) and Bread
To be fair, I do think it is possible to carefully write Business Requirements with a level of precision that makes it difficult to misinterpret them, but then you are essentially having to write requirements with the care of a good attorney; and if you are writing hundreds of these requirements they will get read about as carefully as the Terms and Conditions of consumer software applications and websites that we generally Agree to with the rapid click of a web form button and without a second thought.
The point is: User Stories are much less precise statements of customer or user goals, but they don’t pretend to be precise like Business Requirements often do with their tone of legalistic formality. In fact, a User Story is often the beginning of a topic that is being tentatively investigated. So how can we be confident that a User Story provides sufficient information to ensure that the important User Goals expressed in it and also the specific expectations tied to those goals are delivered? With five little words: We create Acceptance Test Criteria.
To be a bit more precise (because we are worried about precision here), we tie User Acceptance Test Critieria to the User Story. This allows us to validate that our high-level User Story will deliver what’s expected by our customers and users. Cohn gives a good example of this:
…the story “A company can pay for a job posting with a credit card” may have the following written (for Acceptance Test Criteria):
Test with Visa, MasterCard and American Express (pass).
Test with Diner’s Club (fail).
Test with good, bad and missing card ID numbers.
Test with expired cards.
Test with different purchase amounts (including one over the card’s limit).
These test notes capture assumptions….Acceptance tests also provide basic criteria that can be used to determine if a story is fully implemented.
So as long as we have User Stories with User Acceptance Tests tied to them — I can’t believe I am going to say this — We don’t need Business Requirements any more for any project.
Another benefit of this approach is that if we start to define our User Acceptance Tests early, we know, early on — with some precision — what we are talking about, and we can verify that we are on the same page through testing in the early project iterations!
What About Functional and Other Types of Requirements?
I am pretty sure Cohn would not agree with me entirely on this point, but I still do see the usefulness of what Alistair Cockburn calls User Goal Level Use Cases for Functional Requirements (See Cockburn, Alistair. Writing Effective Use Cases. Upper Saddle River, N.J.: Addison-Wesley, 2001). In writing these types of requirements, the process of identifying the functional steps of what will be implemented can often be quite helpful, as long as it does not try and nail down the technical details such that the implementation approach gets prematurely constrained. Some of the other types of more technical requirements that need to be defined on many projects can also be addressed with lower level Use Cases.
My Conclusion: Not to BRD
The vast majority of critical Business Requirements — The requirements that a lot of us project types have worried about for years, because we have always believed that they dictated the scope of projects — are just not necessary to even be written down, so long as we have User Stories with comprehensive Acceptance Test Criteria.
So I am betting that the BRD is on its way to the grave. That’s my story and I am sticking to it.
