This post is part of our Practical Cucumber series.

A common criticism of Cucumber is that clients and stakeholders never actually write the scenarios, and making developers write them is a waste of time.

The stakeholders might not care

The pipe dream of agile development is that stakeholders and developers will harmoniously unite and write perfectly crafted acceptance criteria. But it is very unlikely that clients or stakeholders will write—let alone care about—cucumber scenarios.

We have had a few clients that have tried writing cucumber scenarios, and they did a horrible job. However, a horribly written cucumber scenario is infinitely better than a one-line description of a feature. The client’s attempt to describe the feature in a strict language forces them to think more deeply about the feature, and in the process answer questions that a developer would likely be asking when implementing the feature.

Why developers should still write them

Even if the stakeholder doesn’t participate in writing cucumber scenarios, there’s still value in having developers write them. Thinking about features from the end-user’s perspective forces us to think first about the experience of using our software, and second about implementation. It brings issues to the surface that we might not have otherwise thought about, and helps us write the least amount of code possible to meet the requirements.

This post is part of our Practical Cucumber series.