Skinny User Stories, Fat Unit Tests

One of my colleagues is continuously trying to improve the processes on his project. It is a large enterprisey project with requirements people, testers and a few developers. My friend places high value on knowing exactly what needs to be done and therefor has strived in the past to have very detailed user stories that includes expected behavior and constraints as well as test criteria. He and I had a conversation that restarted his consideration of the user stories. He likes that they are defining the "truth" in only two places, the user story and the code.

While you are defining the truth in two places, I would say that only one of those places has any long term value. The code. As soon as the sprint is completed, your requirements, especially if they live in a tool like Rally, only exist for the sprint where the code is written. After that sprint, it is doubtful that documentation will ever be read again. This is why specs should be light weight. They are only used for a moment in time. Any time that you begin talking about the specs again, you will have to repeat yourself because invariably one person in the conversation will not have a full understanding of the requirements and you won't have the time to send them the requirements to read. Now is a developer going to go through Rally, or any other tool for that matter, to read the requirements for code? No.

The best place to store requirements is in the Unit Tests. Theoretically, you hope to only have one truth, and that one truth has to be the Unit Tests. Every other type of spec is disposable or maybe a better word is perishable. The specs will go away. The contract will go away. The shall statements will go away. The tasks in Rally or JIRA will go away, but the tests will always remain. "Why does this code do
this?" Should always be answered by "look at the test." This doesn't mean leave comments in the test, it means make the test methods the spec.

I've never really been able to put a finger on why I am so against requirements. It seems irrational and crazy. But I think I understand it better now. I have known subconsciously that the requirements are perishable. That they change. They change as soon as you put it in front of someone and show them how it works. The requirements are never absolutely correct. And if they are right, have you put to much time into managing them?

Lessons Learned:
* Requirements are perishable, their shelf life is the length of a sprint.
* Tests are the ultimate "truth" of the requirements of a system.