B - Business Readable (can include technical terms - IF the consumers are technical, e.g. an API product)
R - Read Data - examples should be real data (e.g. VAT calculation should be actual calculation for the nominated item)
I - Intention Revealing - don’t focus on implementation (i.e. ‘click this button’) but on the activity/outcome
E - Essential - only include the elements essential to communicate point. Anything incidental should be removed. If important it can be in another spec
F - Focused
Recommend a pair independently works on prepping the spec based on the examples
After writing specs, share for review with others from the example mapping session (e.g. Product owner to review)
The review is the opportunity to find out how the people who learnt something in the session actually understood what they learnt and if it aligns with the intention
To ensure it’s being reviewed - include ‘incorrect stories’ to find out if they get caught? (Only half joking…)
Timescale... longer than you'd think...
Automation
Drive a test
Cucumber family of tools understand Gherkin (Specflow, Behat, Good)