Well, that was quite a week. I feel I've been on a Behaviour Driven Development "INTENSIVE"... but I've come through it unscathed; I now have a deeper appreciation for BDD than ever before. Enjoy the episode!
Really great and clear explanation. Love the way you have carefully edited the video to make it easier to absorb the information without causing any distractions. Nice!
Three years late - but this was exciting to watch! That... or the coffee kicked in. Or was it both? Did order matter? Should I drink coffee then watch?
A question please: When you say that implementation details should be left to the devolpment team, does this include PO or even the PO should left it for dev team? In the same logic of my misunderstanding: does the PO's work consists of systems requirement (How) or it is also a functional specification (What)? Cuz, I see the what and the how as one calling the other, mading loops!
Great question. The point I was trying to make is that avoiding implementation details in (a) functional specs and (b) behavioural tests ... helps to make them more "robust". ( = less likely to change over time.) But we need to those implementation details at some point... and you're right that this should be collaborative: Product Owners, UI Designers, UX designers ( and, ideally, end users) should all get a say. Is that how you see it?
So basically requirements should never tell the "how." System requirements should define the things the product shall do or qualities the product shall have. In my universe, using a requirement to describe the how, defining the solution.
First thing to say is that it's been a long time since I've seen a specification document of any kind: Agile made them kind of redundant. One of the things that helped me to understand the difference between the "Functional" and the "Systems" docs, is that there could be more than one "Systems" doc: there might be a Systems doc for a Desktop Application, and another for a mobile "App".
Hi Gary. I can see an internal project flowing without the need of any specs doc, just going throught several interactions and molding itself into something good. However, when working for a client who expects quote and timeframe for a feature then I cannot see an alternative apart from writing the doc and a lot of educated guessing. How did/would you approach the conflict of having to "plan everything" ahead vs. doing Agile? I really liked the videos "Agile Estimating - Why bother" but I noticed it is mostly comparing different features as in value/effort, very important once the work is in progress. Now, if you had to estimate the whole system and put a pricetag on it, which approach would you prefer? Maybe your quote will not be approved and any preemptive work could be in vain. Thank you for all your good work!
I see the point to avoid the implementation details but doing so is it not a big risk that there will be gaps in the requirements that the developers will be given too much room for interpretation. So what I am trying to ask is how do one ensure that there are no gaps in the behavioral design allowing for the developers getting it wrong?
"the developers will be given too much room for interpretation" What makes you think that a BA at the start of the project won't have the same problem? How does anyone at the start of the project know what all of the details should be? The reason why big up front design, such as in waterfall, doesn't work is because no one knows what all the details are, or what the best implementation will be. We instead learn these things through the development process, and as such, details should be deferred until the latest possible point. Often this means it'll be the developer who encounters these issues first, but there's no reason why BAs and other team members can't collaborate with the developer as the issue is discovered, and indeed they should.
As a state hater I would argue that "verify" (or "ensure") is an "action" and therefore a "behavior". I think "state" is an old skool term that needs to go away. It's too confusing & ambiguous because it is an abstraction and thus refers to one of many (infinite) levels of abstraction. For example, if you see a corpse can you tell me if it is "alive" or "dead"? The answer should depend on the level of abstraction. At a high level of abstraction we would probably say "of course it's dead, it's a corpse". But at a low level, it is actually full of life -- the life that will consume it, and therefore (arguably) very alive. State can only be determined by making an inquiry, (an action) at some particular level of abstraction. And the answer is only relevant to that exact question, at that exact (infinitesimal) moment. It's like the Schrödinger's cat thought experiment (why all the cat harming analogies, I don't know) where observation (an action) collapses around a particular state. Anyway, I like how you've emphasized that the ordering of related state-related observations is pretty much arbitrary; which makes me think that maybe it's because ideally, in theory, they occur at the same (infinitesimal) moment in time.
When Liz Keogh talks about this she offers up that the outcome step could contain the phrase "should", much in the same way that you've suggested using "Verify" - although looking at this I wonder how that would read. Then the account should be debited And the cash should be dispensed And the card should be returned Written that way...they sound like events don't they? Although they could happen in any order and grammatically make sense. I find that the other is actually important at the outcome stage, but to get that order there should be a discussion in the team to define the behaviour they are going to build. I feel conflicted here as I like both.
I'm conflicted too! Quite like the word "should". You've made me wonder whether a change of tense would help: - Then the account should have been debited - And the cash should have been dispensed - And the card should have been returned Order - as you said - is the tricky one. The "card dip case" has me thinking of "pre-conditions" (in any order) ... the Event.... and "post-conditions" (in any order). Of course, there's an aspect of BDD that I conveniently ignored in the video: the requirement that the steps be executable. Executing means "executing them in order"! There will be cases where we need to be specific about the order, in order to play nice with the executing code... although the resulting order is usually a logical one: - Customer exists - Customer is in credit
The tense definitely makes the word "should" fit more easily, but then do make it more dictatorial as opposed to defining a behaviour? This is Liz's example she uses that has the "should" word in: Scenario: A customer returns an item for refund Given Fred has bought a microwave And the Microwave cost £100 When we refund the microwave Then Fred _should_ be refunded £100 The base structure here is (I'm lifting this from her material): Given a context When an event happens Then an outcome _should_ occur The theory behind the _should_ is that it allows for uncertainty. It allows you to question the behaviour - you say something should occur...but should it? Should it be done now, or should it be done later? Maybe it should do something else. Enter: "useful conversation", stage right. This actually leads me to a point you've made in your reply above: "the requirement that the steps be executable." - there's actually no requirement for the scenarios to be executable, they just have to capture the behaviour. Being executable is a requirement for Cucumber, but it's not a requirement for BDD as it was intended. It is, primarily, an analysis tool - the automation side of things really just leverages parts of BDD to make easily readable test scripts.
"The theory behind the should is that it allows for uncertainty." Now I'm LESS happy with the word "should"! Let's back up a bit: Behaviour Driven Development. My interpretation of "BDD" is that we (a) decide/fix/establish the required behaviour, and (b) write the code to produce the required behaviour. Of course discussion is always a good thing. But we can't have "woolly" scenarios: once we're "cutting code", we need certainty. This MUST be true at the beginning; this MUST be true at the end. The words "Acceptance criteria should be executable" appear as a main headline in Dan's original article (dannorth.net/introducing-bdd/). I can't imagine how BDD would work without executable steps.
Hmmmm yes I see what you mean. So for me the "should" phrase is really there to state (there is that word again) the outcome that should happen, rather than prescribing how it will be done. So you have the conversation and agree "yes, it should do this" and then you need to work out the how. After talking to Dan North at a meetup I got confirmation on a suspicion I had about the term "executable" in that article. He meant it in the sense that the team could execute on building functionality to enable the behaviour, as opposed to it being programmatically executable. This last bit is where Matt Wynne steps in with Cucumber - this does actually make the scenario executable as a test, but they aren't intrinsically the same thing. Or maybe they are now, but they weren't when it was created. I think. It's a bit of a minefield. The main thing is that BDD isn't a test automation framework, but you never state that it is, and that makes me happy.
After sleeping on it something else occurred to me which contradicts what I said above - Dan created BDD with Liz Keogh and Chris Matts when they were working with JBehave....so it must have been executable tests (but not in the Cucumber sense).
Well, that was quite a week. I feel I've been on a Behaviour Driven Development "INTENSIVE"... but I've come through it unscathed; I now have a deeper appreciation for BDD than ever before.
Enjoy the episode!
I am just now reading and trying to learn the process of BDD, I am hoping to learn enough to start trying this process out.
Sounds great! Check back and let me know how you get on.
Really great and clear explanation. Love the way you have carefully edited the video to make it easier to absorb the information without causing any distractions. Nice!
Thank you. You made my day!
This was quite amazing to follow. Very curious about this channel now and can’t wait to check out other videos.
Three years late - but this was exciting to watch! That... or the coffee kicked in. Or was it both? Did order matter? Should I drink coffee then watch?
A question please:
When you say that implementation details should be left to the devolpment team, does this include PO or even the PO should left it for dev team?
In the same logic of my misunderstanding: does the PO's work consists of systems requirement (How) or it is also a functional specification (What)? Cuz, I see the what and the how as one calling the other, mading loops!
Great question. The point I was trying to make is that avoiding implementation details in (a) functional specs and (b) behavioural tests ... helps to make them more "robust". ( = less likely to change over time.)
But we need to those implementation details at some point... and you're right that this should be collaborative: Product Owners, UI Designers, UX designers ( and, ideally, end users) should all get a say.
Is that how you see it?
This video was great. I admire the way you explain concepts and procedures.
Good stuff - still relevant, thanks Gary
Thank you -mglad you liked it.
So basically requirements should never tell the "how." System requirements should define the things the product shall do or qualities the product shall have. In my universe, using a requirement to describe the how, defining the solution.
First thing to say is that it's been a long time since I've seen a specification document of any kind: Agile made them kind of redundant.
One of the things that helped me to understand the difference between the "Functional" and the "Systems" docs, is that there could be more than one "Systems" doc: there might be a Systems doc for a Desktop Application, and another for a mobile "App".
Hi Gary.
I can see an internal project flowing without the need of any specs doc, just going throught several interactions and molding itself into something good. However, when working for a client who expects quote and timeframe for a feature then I cannot see an alternative apart from writing the doc and a lot of educated guessing. How did/would you approach the conflict of having to "plan everything" ahead vs. doing Agile?
I really liked the videos "Agile Estimating - Why bother" but I noticed it is mostly comparing different features as in value/effort, very important once the work is in progress. Now, if you had to estimate the whole system and put a pricetag on it, which approach would you prefer? Maybe your quote will not be approved and any preemptive work could be in vain.
Thank you for all your good work!
So it is a misconception to say Agile has made formal specifications redundant, in my opinion. There should be no doubt that I am requirements focused just based on the amount of time I spend talking about the Volere requirement management process. I believe we need to capture all of the requirements either as part of the marketing effort, customer interviews or stakeholders meetings and it needs to be a formal process. Requirements may change and evolve but having them listed is important for the baseline. This does not and should not imply that I expect the development team to ignore the Agile principals and define the functionality strictly based on requirements. Given that we have captured the requirements, then the team creates the User Stories and defines the functionality to describe the features for the sprints. Tools like JAMA© or DOORS© can map the User Stories to requirements so there is no confusion on anyone’s part as to what the team is attempting to develop and which features are the most important. Also interesting is that before the agile manifesto, there was DSDM and it is considered a forerunner to Scrum, Kanban, etc and used a formal requirements process. I claim that software engineers had a difficult time translating requirements so the user stories came into fashion to address specifications in a natural language format.
Mike - what an awesome post. (Sorry I missed in when it first came in.)
I see the point to avoid the implementation details but doing so is it not a big risk that there will be gaps in the requirements that the developers will be given too much room for interpretation. So what I am trying to ask is how do one ensure that there are no gaps in the behavioral design allowing for the developers getting it wrong?
That's an interesting point; it's a discussion that might make for an interesting future episode?
"the developers will be given too much room for interpretation"
What makes you think that a BA at the start of the project won't have the same problem? How does anyone at the start of the project know what all of the details should be?
The reason why big up front design, such as in waterfall, doesn't work is because no one knows what all the details are, or what the best implementation will be. We instead learn these things through the development process, and as such, details should be deferred until the latest possible point. Often this means it'll be the developer who encounters these issues first, but there's no reason why BAs and other team members can't collaborate with the developer as the issue is discovered, and indeed they should.
Verify is a verb. It’s an event. Verify and ensure are essentially the same thing. No big difference.
Any answer please?
Answered now. (Sorry for the delay.)
As a state hater I would argue that "verify" (or "ensure") is an "action" and therefore a "behavior". I think "state" is an old skool term that needs to go away. It's too confusing & ambiguous because it is an abstraction and thus refers to one of many (infinite) levels of abstraction. For example, if you see a corpse can you tell me if it is "alive" or "dead"? The answer should depend on the level of abstraction. At a high level of abstraction we would probably say "of course it's dead, it's a corpse". But at a low level, it is actually full of life -- the life that will consume it, and therefore (arguably) very alive. State can only be determined by making an inquiry, (an action) at some particular level of abstraction. And the answer is only relevant to that exact question, at that exact (infinitesimal) moment. It's like the Schrödinger's cat thought experiment (why all the cat harming analogies, I don't know) where observation (an action) collapses around a particular state. Anyway, I like how you've emphasized that the ordering of related state-related observations is pretty much arbitrary; which makes me think that maybe it's because ideally, in theory, they occur at the same (infinitesimal) moment in time.
When Liz Keogh talks about this she offers up that the outcome step could contain the phrase "should", much in the same way that you've suggested using "Verify" - although looking at this I wonder how that would read.
Then the account should be debited
And the cash should be dispensed
And the card should be returned
Written that way...they sound like events don't they? Although they could happen in any order and grammatically make sense. I find that the other is actually important at the outcome stage, but to get that order there should be a discussion in the team to define the behaviour they are going to build.
I feel conflicted here as I like both.
I'm conflicted too!
Quite like the word "should". You've made me wonder whether a change of tense would help:
- Then the account should have been debited
- And the cash should have been dispensed
- And the card should have been returned
Order - as you said - is the tricky one. The "card dip case" has me thinking of "pre-conditions" (in any order) ... the Event.... and "post-conditions" (in any order).
Of course, there's an aspect of BDD that I conveniently ignored in the video: the requirement that the steps be executable. Executing means "executing them in order"! There will be cases where we need to be specific about the order, in order to play nice with the executing code... although the resulting order is usually a logical one:
- Customer exists
- Customer is in credit
The tense definitely makes the word "should" fit more easily, but then do make it more dictatorial as opposed to defining a behaviour?
This is Liz's example she uses that has the "should" word in:
Scenario: A customer returns an item for refund
Given Fred has bought a microwave
And the Microwave cost £100
When we refund the microwave
Then Fred _should_ be refunded £100
The base structure here is (I'm lifting this from her material):
Given a context
When an event happens
Then an outcome _should_ occur
The theory behind the _should_ is that it allows for uncertainty. It allows you to question the behaviour - you say something should occur...but should it? Should it be done now, or should it be done later? Maybe it should do something else. Enter: "useful conversation", stage right.
This actually leads me to a point you've made in your reply above: "the requirement that the steps be executable." - there's actually no requirement for the scenarios to be executable, they just have to capture the behaviour. Being executable is a requirement for Cucumber, but it's not a requirement for BDD as it was intended. It is, primarily, an analysis tool - the automation side of things really just leverages parts of BDD to make easily readable test scripts.
"The theory behind the should is that it allows for uncertainty." Now I'm LESS happy with the word "should"!
Let's back up a bit: Behaviour Driven Development. My interpretation of "BDD" is that we (a) decide/fix/establish the required behaviour, and (b) write the code to produce the required behaviour.
Of course discussion is always a good thing. But we can't have "woolly" scenarios: once we're "cutting code", we need certainty. This MUST be true at the beginning; this MUST be true at the end.
The words "Acceptance criteria should be executable" appear as a main headline in Dan's original article (dannorth.net/introducing-bdd/). I can't imagine how BDD would work without executable steps.
Hmmmm yes I see what you mean. So for me the "should" phrase is really there to state (there is that word again) the outcome that should happen, rather than prescribing how it will be done. So you have the conversation and agree "yes, it should do this" and then you need to work out the how.
After talking to Dan North at a meetup I got confirmation on a suspicion I had about the term "executable" in that article. He meant it in the sense that the team could execute on building functionality to enable the behaviour, as opposed to it being programmatically executable.
This last bit is where Matt Wynne steps in with Cucumber - this does actually make the scenario executable as a test, but they aren't intrinsically the same thing. Or maybe they are now, but they weren't when it was created.
I think. It's a bit of a minefield. The main thing is that BDD isn't a test automation framework, but you never state that it is, and that makes me happy.
After sleeping on it something else occurred to me which contradicts what I said above - Dan created BDD with Liz Keogh and Chris Matts when they were working with JBehave....so it must have been executable tests (but not in the Cucumber sense).
what about Chris Matts, it wasn't Dan North alone.
You're right. Chris Stevenson should also have got a mention.