I was packing up my things, ready to leave after a long week of training. Susan, the lead business analyst, had been dutifully attentive all week. She took excellent notes, asked probing questions, and seemed to be integrating the new knowledge smoothly.
“Hey Tirrell, I have a question for you…”
“So exactly how are user stories different from requirements?”
When people say “requirements”, especially in my neck of the woods, they are referring to IEEE Standard 830 “The system shall” style of writing requirements. Here are some examples:
- 1.2) The system shall allow a user to buy a cake with a credit card
- 1.2.1) The system shall accept Visa, Mastercard, and American Express
- 1.2.2) The system shall charge the credit card before the cake is made
- 1.2.3) The system shall give the user an order number
You get the idea. One problem with documenting requirements this way is that its very very tedious and time consuming. Another problem is that its boring to do, and even more boring to read, which is why long detailed requirements documentation rarely gets read. Lastly, because requirements are written at such a granular level, its difficult to understand the big picture.
User Stories are Goal Oriented
Traditional requirements are created from the perspective of the system and its associated activities. Problems with interpretation of these activities lead to pain and missed deadlines because they tend to be interpreted as edicts rather than points of discovery. In other words, they tend to over specify. This leads us to a situation where highly paid intelligent engineers don’t get the opportunity to solve user’s problems, they are stuck implementing a sub optimal solution.
Unlike traditional requirements, user stories tell is what the user is attempting to achieve. This is important because it gives context to how we view the requirements. Since there are multiple ways to help a user accomplish the goal, it ensures the solution meets the goal (or the problem the user is trying to solve).
User Stories Allow for Quick Level of Effort Estimates
In waterfall, there is a traditional requirements gathering phase that may be 20-30% of the overall project timeline. Therefore, the team doing the work can’t give estimates until after the specifications have been written. This leads to friction because the teams are often railroaded into a timeline that doesn’t match with the requirements, but the timeline and budget were decided before the specs were written. Catch 22.
With User Stories, a team can look at what the user is attempting to achieve, and give an associated estimate usually within minutes or hours rather than the weeks or months associated with traditional requirements.
User Stories Allow for Negotiable Scope
Traditional requirements tend to be “all or nothing” and have no sense of prioritization. Therefore, the scope of traditional requirements is not negotiable. This can lead to what is known as “value engineering”, which is the practice of creating quick, but fragile solutions as to get all the functionality completed on time.
With user stories, if the level of effort estimate is different from what the project sponsors thought, the team and product owner can take a look at the goals of the users in the stories, and think of other, less feature rich (but still usable) ways to help the user achieve their goals.
IEEE Standard 830 was last updated in 1998
A lot has happened in software development since then, but many companies have not yet revisited how they create requirements, so I still see a lot of this in the field. Often, its because a decision was made 15 or so years ago to write the requirements this way, and armies of business analysts were hired to support this decision. In short, continued use of IEEE 830 style specs is just as much a function of inertia as it is conscious decision making.
How do you write specs at your company?