Requirements

A previous post argued that Dev, QA, and Product read the same requirement differently not because anyone is careless, but because prose leaves three things implicit — the precondition, the action, and the outcome — and that a structured format forces those three things into the open. It also argued that the specific tool doesn’t matter much: Gherkin’s Given/When/Then is one well-known way to get the structure, not the only one, and a team is free to define its own. ...

A pattern shows up on almost every team I’ve worked with, regardless of how disciplined the process otherwise is: Dev, QA, and Product each walk away from the same requirement holding a slightly different picture of what’s being built. It rarely surfaces at the moment the requirement is written. It surfaces later, and by then it’s expensive — a bug report that turns out to be a misunderstanding, a scope argument in the middle of a sprint, a story that stalls because QA and Dev quietly disagreed about what “done” meant and neither noticed until the story was in review. ...