Who should write and own feature files in a BDD team, and how do you prevent them from becoming stale?

Ideal process — Example Mapping: Before a story enters a sprint, a 3-amigos session (30–60 min) uses index cards to map:

• The rule (business rule being implemented)
• Examples (concrete scenarios that illustrate the rule — these become Scenarios)
• Questions (unknowns that need answering before implementation)

This conversation is more valuable than the Gherkin — it surfaces edge cases and misalignments early.

Who writes the Gherkin:

• Business analysts draft the Given/When/Then in business language.
• QA refines for testability and completeness.
• Developers review for implementability and add missing edge cases.
• No one person owns it unilaterally.

Preventing staleness:

1. Living documentation — scenarios that don't run fail the build. If a feature changes, the feature file must change too.
2. Review in sprint retros — walk through feature files for the features shipped that sprint.
3. Scenario tagging — @wip for in-progress, @deprecated before deletion, never leave dead scenarios commented out.
4. No duplication — if a scenario is covered elsewhere, delete it rather than leaving a second copy.
5. Business review cadence — product owner spot-checks feature files quarterly to confirm they still reflect intent.

The staleness smell: Scenarios that refer to deleted UI elements, retired features, or old naming are a sign the update discipline has broken down.