One of the benefits of having the customer (or someone else) write the scenario is that we get to be the critic and not the author. We can focus on the scenario and ask questions like: does it read well? Is it doing too much? Is doing little? Can I understand its intent? etc. etc.

When working with a pair our pair should really challenge us to write good, communicating, intention revealing scenarios (just like they should be doing with code). This can be hard when we are working solo because we may just be staring at the screen for too long, and we can’t see the forest for the trees. If that’s the case grab someone else for a quick review, even if it’s after you finish implementing the scenario. Refactoring applies to scenarios to.

Scenarios are like code, if we don’t tend them well, they will grow messy and hard to maintain. We are best served to spend a little time upfront to keep them tidy rather than wait until we have hundreds of steps that don’t do a good job of communicating and require people to have to read through all of the step definitions to figure it out.

Go forth and code! ;)