This post should hopefully keep your discussions on track and help you use BDD correctly.Starting with my preferred format, introduce your product owner and business resources to this concept:
In order to <achieve something which contributes to the release vision>
As a <role>
I want <feature>
The idea here is to focus on the users goal in relation to your pre-agreed release vision.
Point 1 – Get business resources \ product owner to write the stories
Your product owner is the person that is driving what they want so allow them time and space to brainstorm. Get your business people to write the stories themselves so that they begin to own the requirements. I prefer story maps for this. Keep the number of developers to a minimum and don’t let them interrupt this initial activity. After the stories are in a sensible order you can then start the discussions with development.
Point 2 – Keep solutions out of the way
In order to immediately notify users of going over their credit limit
As a bank Manager
I want to send an email to a customer
The above seems quite simple why not say email? The business people have written this and have inadvertently specified a solution. This will lead to a whole email system being created in stories. What if phone texting was a better solution! Change the final sentence to “I want to inform a customer”. Even worse is if you want your work derailed by technologists who will solution every story they can and slow up the whole process. Every time the team talks about solutions in the early stages I get them to stop and focus on the business goal.
Point 3 – Generate Main Scenarios
Now we can talk about scenarios. Start with the happy path through, where the inputs are all valid. Here I’m using inputs for an application form, I have a name, DOB and address.
I like to use grids with a column for each input for this type of work, they are simple to lay out and avoid us talking about clicking buttons and other UI artefacts.
Start by putting some real inputs in, John Smith; 19/12/2001; The Grange, London Road, London, TW2 7WD. This gets us started. Now we can look at what happens if we input a DOB that makes them over 100 years old, or even American addresses. By talking through the potential scenarios we make the software more robust.
Point 4 – Now move to solutions
After you’ve understood the required business process and goals you can then look at an optimised solution holistically. You’re ready to discuss what items such as the user interface and feed these into your estimation. A negotiation usually takes place around the cost of various solutions too as the optimal one may be too expensive. Estimation is done as a team.