物語から、私はあなたが自分でコーディングしていると推測します。
通常、BDDの目的は、特にビジネスと開発者の間の会話を可能にすることです。これにより、チームは彼らが共通の理解に達したことを確認できます。テスターを含めることも好きです。テスターは、シナリオを見逃したときに見つけることができるからです。
自分でこれを行う場合は、ゴム製のアヒルをつかんで、アプリケーションの動作をアヒルに説明してください。それがどのように機能するかの例をいくつか挙げてください。それらはあなたのシナリオになります。
まず、これらのシナリオを自動化しないことをお勧めします。必要に応じてそれらを書き留めることができます。アヒルと共有したビジネス上の成果は、それらを表現するのに適切なレベルであることを忘れないでください。これで、アプリの動作のアイデアが得られ、シナリオを手動で実行できます。まだ機能しないものはすべてバグのように扱いたい。私は時々自動化から始めましたが、システムがどのように機能するかをよく知っていて、ツールに精通していて、UIがよく理解されている場合に限ります。それでも、コードを記述したときは、少し手直ししなければならないことがよくあります。
下位レベルでは、各クラスがどのように動作するかをアヒルに伝えます。いくつか例を挙げてください。ゴム製のアヒルは、技術用語を完全に理解できます。これで、ユニットレベルのBDD、つまり単体テストが作成されました。ここでは、赤、緑、リファクタリングのサイクルが発生します。（クラスの責任について考え、ビジネス指向の言語で表現しているので、これ以上リファクタリングする必要はありません。それはとにかく非常に美しい方法で抜け落ちる傾向があります。しかし、しばらくの間これを行っています。実行しても問題ありません。）
あまりリファクタリングしないでください。私たちには、コードについてフィードバックが欲しいのです。なぜなら、わからないことが常にあるからです。完璧はここであなたの敵です。十分に良いものにし、読みやすくし、次に進みます。さらに変更を加えるために完璧なものを作成する必要がある場合は、さらに変更を加えるときに行います。
ビジネス関係者からシナリオに関するフィードバックを得る機会があるが、彼らがあなたと一緒に座っていない場合は、その時点で書いてすぐに、それを自動化する前に、シナリオを彼らに送信できます。UIのモックアップも送信して、単語をアクションに関連付けることができます。これを使ってコーディングの先を行き過ぎないでください。すでに行ったことは間違っているという前提で作業します。その方法を見つけるにはフィードバックを得る必要があります。
最後のヒントとして、一般的にユーザーの視点からストーリーをフレーズしないでください（シナリオではありますが、ストーリーではありません）。それらはユーザーストーリーではありません。それはおそらく次のようなものになるはずです：
In order to attract people to my website
As @thom
I want users to easily convert months and days to days.
とにかく、あなたが探しているより高いレベルの目標があります。これは、必要な機能を引き出すのにも役立ちます。幸運をお祈りします。また、投稿が長すぎることをお詫びします。