The BDD discussion was fantastic. It was primarily driven by a need for people to understand where it fits into the development process. One of the primary questions was where does it fall in the lifecycle of the development process and where do you go once you have worked with it? I don’t know that this was answered. We’ve moved onto how this relates to working with the client. Should we be working in code to document the converation when the client is in the room? Should we be exposing them to our side of the world at this point in the process? I would think that I want the client to stay in their sphere of knowledge during the conversation and then move the conversation to the technical realm. We also need to keep the story accessible to the BAs and end users. They need to be able to get to the story when they need or want to, whether that is just to view them or to modify them. Scott H. points out that specification is nicely forcing the verbage structure within the story. Index cards are dynamically typed. People can write the story in any format that they want. Story cards and specification frameworks are not for traceability and will not stand the test against regulators. I think that code based story writing is an attempt by the developer to retain control of the process and, most dangerously, the contents. Arguments are being made that this is a tool for bridging the gap between the BAs and the developers. After it is used to gather and “codify” the english language specification it becomes an acceptance test. Before that point it’s not a test. Another valuable and passionate discussion.