Using it for a current project: Phase 1 Non-technical and semi-technical business analysts write scenarios as acceptance criteria for the requirements. They

Using it for a current project: Phase 1 Non-technical and semi-technical business analysts write scenarios as acceptance criteria for the requirements. They are still so high level that the devs need to re-write or refactor the majority of them to be able to get any sort of re-use out of them. Phase 2 Writing scenarios is largely seen as a time sink and the test coverage is falling behind. This is then changes so that the BAs write a headline scenario and some high-level bullet points (higher level than they were doing already) which are then fleshed out by devs. Devs re-write statements in ways that aren't very good english ('When I log in as a "Tim_test5"') and scenarios are no longer good to show to the customer. Phase 3 Test writing is still slow, so BAs and testers start writing and performing manual tests to close the user stories. Step 'library' and feature files are building up but still only a relative handful of tests are automated. So yeah, in an ideal world they would be perfect, but I would recommend the following: * Don't include BDD in your 'definition of done'. You will never close anything. * Only write BDD for things that are stable - some changes can mean that tests need to be updated, split or take more arguments. Syncing up changes to statements in feature files is extra overhead. * Deciding on wording to reflect business meaning of a statement and technical meaning of a statement is harder than you think. Factor in time for this. * If your team haven't used BDD before, create some central resource with statements in that can be used by non-technical users to build up scenarios lego-style. If what they need isn't there, then it can be added. This is especially true when a set of actions is easily abstracted to a single business action ("I send the request" or something which takes many clicks and form filling).