Today, i had the true pleasure of presenting my view of how BDD stories offer real business value to project delivery, quality and to the lives of everyone on a software delivery project.
Part 1: Collectively clarify what happens on projects now (on projects that do not use stories)
It was a highly interactive session and i first asked attendees to collectively draw on a whiteboard the project process as they saw it, with all of the project’s actors, products and interactions.
What was drawn resembled a kind of mashup of a UML activity diagram with swim lanes & a gantt chart. It showed what the individual actors in the process did and when, and who fed into who in the process.
Part 2: Clarify what documents are written and the associated risks and costs
When the whiteboard was complete, I asked the attendees to consider a number of things:
- At what points during the process are documents produced and by who?
- Of those documents produced, which are directly focused on the business and user requirements?
- Of the many producers of those documents, which of these producers had their focus on the business and user requirements?
- Of the many documents produced, which were open to interpretation and translation?
- What are the perceived risks of having so many documents and periods of documentation translation?
When this work was complete, a few points became clear to the group:
- The project team, as defined on the whiteboard, was greatly separated into areas of expertise and each was concerned about their area of expertise
- Interactions between actors were mostly through written documents
- Few actors following this project process retained a direct focus on the business and end user requirements
- A lot of documentation was being written and much of it was being duplicated, at times to protect actors within the process
- Vast amounts of document interpretation and translation was going on to produce each document
Part 3: Consider stories
After this part of the session was complete, i gave some examples of the wonderfully simple story DSL and then suggested that many of these documents could be replaced by stories and scenarios:
- I explained that stories can be used to clarify both high-level requirements and detailed solution definitions. I described how stories can be expanded through the use of scenarios.
- I described how everyone on the project, including the client, can understand the wonderfully simple DSL and contribute to the bank of stories.
- I then came in with the ace Stories can be used to drive automated browser tests! Man, they fell off their seats at the point!
It was an awesome session. A lot was discussed and understood.