Storytest Driven Development

During iteration planning, members of the customer and developer communities engage in a good deal of dialogue about UserStories and estimates. Such dialogue helps to establish understanding of story details and scope. Yet I have found that relying purely on dialogue oftens leads to misunderstandings and defects. The rubber still needs to meet the road. Concrete examples help make that happen. Examples help clarify story details and pinpoint what is in or out of scope. I call such concrete examples "storytests." I also like to refer to them as ExecutableSpecifications.

Communities that do StorytestDrivenDevelopment (SDD) work collaboratively on storytests. A domain expert may write some storytest details on a whiteboard while a QA person looks on and asks questions. The QA person may later produce an electronic version of the storytest and check it into to a version control system. Next, developers collaborate with the QA person and domain expert (if she is accessible) to understand and then automate the storytest. Lots of dialogue between members of the customer and developer communities happens throughout this process.

Not enough has been written thus far about SDD. That's probably a good thing. We continue to discover where it works well, where it gets in the way and what tools are best for actually doing it. I'm excited about the tool Rick Mugridge is developing and plan to use it on some client gigs very very soon. I believe Rick understands that customers and developers need an entirely different way to build and interact with an SDD tool. --JoshuaKerievsky (p.s. I will fill in more details about SDD on this page when I have more time).