How User Stories are Different from Requirements

This post is a part of a series:Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask

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?”

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 documentationrarely gets read.  Lastly, because requirements are written at such a granular level, its difficult to understand the big picture.

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).