Spec. documents are faulty, they are often too cumbersome to read (let alone write). They dive into such specifics that the developer may assume that all the details is addressed. That’s when pragmatic thinking and common sense are taken out of the equation.The preferred method is to tell the development team a story; a very simple one sentence story. This story has a single character who is trying to achieve a single task, such as “As a frequent flyer, I want to be able to check how many mileage points I have” or “As a parent, I want to be able to see my student’s grades”.   That’s all that’s needed that’s the story.

Unlike a spec document, this story is not contractual, it is the desired goal, which can be complimented with the criteria of how this was be deemed acceptable (i.e. “All grades are displayed together; Parents can see grades, but public can not.”).

Suddenly, the development team is back to doing what they do best, providing solutions.  They are driving how they will technically achieve this goal to fulfill the story, based off the acceptance criteria.