Breaking down technical (non)user stories!

There’s plenty of articles discussing patterns for breaking down user stories… I’ve even written the odd article myself.

But what about breaking down large complex non-user stories? I often warn of the danger of creating too many non-user stories or too many technical stories as they can tend to lead to horizontal development thinking as opposed to vertical slice delivery and make enforcing a definition of done less transparent…. However some systems simply don’t have user stories – Or at least not many!


This is real user-story from one such system….


“As a customer of …… bank I would like to purchase half a billion Euro’s in sterling for the best rate available”


This was a user story I was discussing with a product owner for a large bank who was struggling with this issue – The system they were developing dealt with High Frequency trading and was mainly algorithmic based.


The system had to purchase a given quantity of a currency at the best possible exchange rate and hopefully without pushing the value of said currency up (too much) during the purchasing.


The product owner wanted to use user stories, Planning poker to estimate and deliver fully working, fully tested code each sprint and demo it!


Traditionally in a user story we would write something like…


As a user…..

I want……

So that…….


We would further defining the criteria with BDD (Behaviour Driven development) a possible BDD scenario for our bank customer could be….


Given… The exchange rate is 0.69 = 1 Euro

When…. I purchase 100,000,000 euros

Then…. I’m able to purchase for no more than £69,000,000


We came up with the idea of treating technical parts of the system as users - We even discussed the idea of giving each part it's own persona and name (But we were perhaps getting a little carried away at that point!)


  • As an API when I receive a request to check the value of transactions in a currency since trading began today I will return a message with the following details.......

  • As a listener I want to be alerted when the exchange rate varies outside of a defined tolerance


Those 'user' stories are still a little high level and you would probably want to break them down further.

  • As a listener (ListerName) I want to receive a 12000 message containing (..........) when the value of sterling against the value of the euro drops below the value held in dbo.clientprojection.MaxExchangeRateValue

  • As a listener (ListerName) I want to receive a 12005 message containing (..........) when the value of sterling against the value of the euro drops rises above the value held in dbo.clientprojection.MinExchangeRateValue


These stories would then be surrounded with Behaviour tests and written up using the Gherkin language.

In this way although the coding is much more 'invisible' as compared to a system with user interactions the PO would still be able to monitor progress.

The delivery of each sprint would be 'potentially shippable' and indeed could be put live even though it might not add business value it would allow the release procedures to be tested and the system monitored in a live environment before being used in anger!

It also allowed for the PO to enforce the definition of done, Track velocity and make a very invisible system visible.




Christian MilesUnited KingdomBDD, TDD, Technical Stories, User stories