I am working on a team that is adopting BDD for the first time. We are doing greenfield work building a market data system that allows users to request market data from different sources.We are using Mingle (https://www.thoughtworks.com/mingle/) and the BDD card hierarchy that has been set up is: A release consists of one or more iterations and an iteration consists of one or more stories. A story is expressed in the BDD format of: As a <type of user>, I want <some goal> so that <some reason>As stated, this is a greenfield project so there is nothing currently in place. From a BDD perspective we have captured end-user system requirements with stories like:As a user I want yesterday's end-of-day prices available each morning so that I can use them as inputs to my models.As this is a completely new project this single story requires quite a lot of technical tasks to be completed e.g.:Build a scheduler Build a gateway to connect to the external market data source Get a database to hold the results etc...I am entirely unsure how to track these technical tasks against my story in a BDD format.  What am I doing wrong? Are the stories to high level? Is there a level in the release -> iterations -> stories hierarchy missing? Is BDD  not suitable for this and, if not, what are other people doing? Something else?
How to track technical tasks with BDD?
bdd
It's natural for your first few stories to have a lot of overhead, and in the beginning it's even common to have stories that do not amount to a BDD test. You need to set up repositories for your code, configure CI servers, lay out your basic project structure, build files, etc... Some things just take time and don't deliver any business value to your customers, but business value can be some value that is added for you as well. You can pour these into a story too: remember that the role in BDD is not limited to users. A story that reads as a developer, I want the application to be built nightly is a valid story!As your project grows, stories can speed up because you will have the infrastructure. You first story might encompass the need to build a sandbox database with a single script-file you can execute, but all the other stories will benefit from that. This needs to be taken into account if you do estimations, obviously, but there is no need to shy away from doing this.Remember that you can also start with a more simple story: you could simply have a story where As a user I want to be able to retrieve a list of end-of-day prices. That eliminates the scheduler and the gateway. Iterate over that so that As a user I want to be able to update the end-of-day prices with those in the external system and finally as a user I want the update to the end-of-day prices to occur automatically every night. The first story gets you the database, the second one gets you the gateway and the third one the scheduler.