How to track technical tasks with BDD?

Question

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?

Answer 1

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.

Answer 2

You are making a mistake by skipping the sprint 0.

In sprint 0, you should preprare everything (architecture, design, build system, frameworks, etc). After you finish sprint 0, you can start delivering buisness value.

Another option is to add some stories in sprint 0, but give it enough time to prepare everything I listed. This way, you deliver some business value.

---

Just to make it clear, sprint 0 should deliver :

• The team needs to be assembled in Sprint Zero
• Organization and logistics need to be set up in Sprint Zero
• Consider planning, product backlog setup, and design