While working with one of our clients over the past few months, we had a large “us and them” divide between their business and technical staff. We quickly realised that we needed a common language that would build a bridge between the two groups. Of course, being a BDD adept, I thought that User Stories (as nicely described in Dan North’s article) would be a great language for that as they provide a natural way that’s business and technically agnostic, it sees the features from the perspective of the user/consumer and provides a series of acceptance criteria which describe the important conditions that the feature needs to fulfill.
What we saw was that writing user stories in this format brought the business and technical people together as it wasn’t centered around the technical implementation aspect of the feature or the business jargon. We all learned to “step into the user’s shoes” very quickly and were able to have conversations with a certain formalism were we could understand each other. As a technical person, I had to force myself to think of a feature in terms of how the user was going to be using it and not in terms of its implementation, at least not during the time of writing the user story, which gave me the freedom to decide on the implementation at Sprint planning or during the Sprint itself.
Don’t be fooled by the simple formalism of the user story format, it’s actually very hard to write features down using this approach however the benefits are way more than the effort. Especially having a good set of acceptance criteria (I will describe this in another post) is invaluable!
I can’t really use any of the examples from our client, however I will use the one from Dan North’s article (read it, it’s a very good description of the characteristics of what a good user story looks like) so that you can see how a user story might look like and how self-explanatory it is:
Story: Account Holder withdraws cash As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed Scenario 1: Account has sufficient funds Given the account balance is $100 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned Scenario 2: Account has insufficient funds Given the account balance is $10 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be $20 And the card should be returned Scenario 3: Card has been disabled Given the card is disabled When the Account Holder requests $20 Then the ATM should retain the card And the ATM should say the card has been retained Scenario 4: The ATM has insufficient funds ...
While doing some research for this post, I found this talk by Martin Fowler and Dan North titled “The Yawning Crevasse of Doom” in which they go over this problem and come to the same conclusion, that “the biggest difficulty we face in software development is the communication between customers/users and the developers”. Now I wish I had seen their presentation before my engagement as it would certainly have helped me with some more concrete arguments (also using a reference like Martin Fowler or Dan North is extremely helpful 😉 ).