The book is quite ok (although a bit tedious in it's examples). I do recommend reading it!

My sense of BDD after this book:

You get 'mostly' feature coverage, but as a byproduct, although it is a byproduct not of organizing the system but of exploring and defining the high-level functionality of your application.

It has several strategies to explain how to not get bogged down in infinitely running tests as well as how it evolved from TDD.

All in all, it seems BDD requires a bigger organisational 'buy-in' than TDD (and has also bigger promises). In the sense that I can TDD without anyone's but in, and maybe convince 'by example', but in the end it does not really matter that all the team TDD's. Whereas for BDD to be useful as described in the book, the whole 'team' (in it's widest sense, including even users) needs to buy in.

It's promises are quite interesting though, and present a cycle of red-green-refactor made up of a lot of red green refactors.

I think when I 'naively' tried it in the past, my main mistake was assuming that the cucumber scenarios should not be done by the tech team (in close collaboration with the stakeholders)

The promises of being able to better discover features and edge cases via examples while making collaboration with 'business' easier is quite appealing

After reading the book, if I am ever in position to try BDD again I would like to give it another go