Feedback sought on BDD Process Diagram

[Stephen Kurlow]

I am attempting to produce a diagram that shows:

1) 3 Amigos in a workshop preparing Acceptance Criteria for a new Story.

2) Turning each acceptance criterion into Acceptance Test Glue Code and Application Code step by step until the complete acceptance test passes for every step

3) Once all acceptance criterion have been turned into acceptance test glue code and application code then the story is Done.

Obviously other good software engineering practises are being ignored so I'm just focusing on the core BDD process.

A couple of questions:

1) Can you identify with this process?

2) If not how is your process different?

3) How can you suggest this diagram be improved? BTW, I'm not the best drawer. :)

Thanks,

Stephen Kurlow

[Liz Keogh]

Hi Stephen,

I differentiate between scenarios and acceptance criteria. A criterion is a business rule. That might be something like:

 - Customers who qualify for refunds should receive the same amount of money they paid.

But a scenario is an exemplar; an example that illustrates the particular rule. So it would be something like:

 - Given Fred bought a microwave for £100 on 10% discount, when he asks for a refund then he should receive £90.

Because you can think of the specific examples, it's now easier to see that there might be other scenarios too.

 - Given Fred bought a microwave for £100 with £20 3-year insurance

 - Given Fred bought a fridge-freezer for £200 (but it's still at his house)

So you might end up with multiple scenarios per business rule, depending on how you phrase the different contexts.

More on that here. One of the most common anti-patterns I see is people thinking they've got scenarios when they've actually just got acceptance criteria phrased in Given-When-Then form. More usually I see acceptance criteria come into the 3 Amigos meeting (normally via the BA), then be turned into scenarios as the result of that meeting.

I also prefer to use the word "automated scenario" rather than "acceptance test", which goes back why Dan originally thought of BDD in the first place. You could just use "Automation Glue Code" instead of "Acceptance Test Glue Code".

Other than that, it's a good diagram. I particularly like the emphasis on getting one scenario working at a time! Thank you.

Cheers,

Liz.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[Stephen Kurlow]

Thanks for your feedback Liz!

On Saturday, 28 February 2015 00:15:35 UTC+11, Liz Keogh wrote:

Hi Stephen,

I differentiate between scenarios and acceptance criteria. A criterion is a business rule. That might be something like:

 - Customers who qualify for refunds should receive the same amount of money they paid.

First project where we practised BDD we decided to effectively do that too but called them requirements with a unique tag and had them all itemised at the top of the story. Then each scenario made reference to them by their tag so we knew which scenarios were applying one or more requirements. I've found this aspect of BDD not formalised very well. I see the value in doing it just didn't realise it was expected rather we thought we were doing it because the customer insisted on wrapping a 'waterfall' SDLC around the inner Agile SDLC.

But a scenario is an exemplar; an example that illustrates the particular rule. So it would be something like:

 - Given Fred bought a microwave for £100 on 10% discount, when he asks for a refund then he should receive £90.

Because you can think of the specific examples, it's now easier to see that there might be other scenarios too.

 - Given Fred bought a microwave for £100 with £20 3-year insurance

 - Given Fred bought a fridge-freezer for £200 (but it's still at his house)

So you might end up with multiple scenarios per business rule, depending on how you phrase the different contexts.

Yep agreed like I mentioned above in more detail. 

More on that here. One of the most common anti-patterns I see is people thinking they've got scenarios when they've actually just got acceptance criteria phrased in Given-When-Then form. More usually I see acceptance criteria come into the 3 Amigos meeting (normally via the BA), then be turned into scenarios as the result of that meeting.

Yes we mistakenly tried that a few times early on and realised it is not effective even just simply from a time perspective. Focusing on just the acceptance criteria during the 3 Amigos workshop is best. 

I also prefer to use the word "automated scenario" rather than "acceptance test", which goes back why Dan originally thought of BDD in the first place. You could just use "Automation Glue Code" instead of "Acceptance Test Glue Code".

I will read the articles you linked soon. Without reading them yet I thought Dan was exploring challenges in teaching TDD to students which is a developer centric activity and then with the help of Chris Matt they explored moving into the requirements/analysis phase so 'it' became more valuable to the whole team from the beginning of a SDLC for developing a story from 'ideas' to Done (consumable in a test/production) env?

Other than that, it's a good diagram. I particularly like the emphasis on getting one scenario working at a time! Thank you.

Thanks. :) I will incorporate your feedback and refine it. When that is done I will post another. 

Cheers,

Liz.

On Fri, Feb 27, 2015 at 12:49 PM, Stephen Kurlow <sku...@gmail.com> wrote:

I am attempting to produce a diagram that shows:

1) 3 Amigos in a workshop preparing Acceptance Criteria for a new Story.

2) Turning each acceptance criterion into Acceptance Test Glue Code and Application Code step by step until the complete acceptance test passes for every step

3) Once all acceptance criterion have been turned into acceptance test glue code and application code then the story is Done.

Obviously other good software engineering practises are being ignored so I'm just focusing on the core BDD process.

A couple of questions:

1) Can you identify with this process?

2) If not how is your process different?

3) How can you suggest this diagram be improved? BTW, I'm not the best drawer. :)

Thanks,

Stephen Kurlow

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Stephen Kurlow]

Hi Liz,

What do you think of this refinement in the diagram? It shows:

• Scenario #1 is an example of AC#1
  
• Scenario #2 is an example of AC#2
• Scenario #3 is an example of the combination of AC#2 and AC#3.

Regards,

Stephen

On Saturday, 28 February 2015 00:15:35 UTC+11, Liz Keogh wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Liz Keogh]

Hi Stephen,

You really do want to be getting scenarios out of that workshop; at least for anything which requires expertise.

I find a lot of the people who are taking too much time over this are either:

- trying to talk through them with the entire team

- trying to have conversations using Given, When, Then rather than just having conversations

- talking through all the scenarios, even for things which are boring and really well understood like Login

- trying to talk through scenarios for things which are highly uncertain, and in flux.

With those last two, I've seen more than one client hack serious quantities of time out of their planning sessions and 3 Amigos workshops by not doing that. Some of them are using my complexity estimates, others are using BDD as a sensemaking technique, or a combination of both.

Hopefully those links will help you too.

Cheers,

Liz.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Liz Keogh]

On Fri, Feb 27, 2015 at 10:00 PM, Stephen Kurlow <sku...@gmail.com> wrote:

I also prefer to use the word "automated scenario" rather than "acceptance test", which goes back why Dan originally thought of BDD in the first place. You could just use "Automation Glue Code" instead of "Acceptance Test Glue Code".

I will read the articles you linked soon. Without reading them yet I thought Dan was exploring challenges in teaching TDD to students which is a developer centric activity and then with the help of Chris Matt they explored moving into the requirements/analysis phase so 'it' became more valuable to the whole team from the beginning of a SDLC for developing a story from 'ideas' to Done (consumable in a test/production) env?

Read the article. ;)

Cheers,

Liz. 

[Stephen Kurlow]

Hi Liz,

Yes makes sense to not elaborate scenarios during the 3 Amigos workshop. Do you think my diagram means to infer that scenarios are written during 3 Amigos. That wasn't my intention.

Regards,

Stephen

		Stephen Kurlow about.me/skurlow

--
You received this message because you are subscribed to a topic in the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/behaviordrivendevelopment/Hra7O4fas8Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to behaviordrivendeve...@googlegroups.com.

[Stephen Kurlow]

Hi Liz,

Dan North describes in that article that Acceptance Criteria should be expressed in the form of Given/When/Then. Excerpt from his article:

We started describing the acceptance criteria in terms of scenarios, which took the following form:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

I could be wrong but I suspect what happened with the inventors and early adopters of BDD is that BDD evolved and Acceptance Criteria was changed to not be about the scenarios.

What is your take on that?

Regards,

Stephen

[Stephen Kurlow]

Hi Liz,

I've amended my diagram. I'm happy to not use the term Acceptance Test. Maybe it also helps because we are reducing the amount of terminology too. Personally I don't like using multiple terms having the same meaning. When newbies here them they think there are more than one concept that needs to be understood.

Regards,

Stephen

On Saturday, 28 February 2015 00:15:35 UTC+11, Liz Keogh wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Liz Keogh]

Some people write them during the workshop. I think if there's stuff that comes out that's surprising, that's a useful thing to do. Otherwise I recommend devs write them down afterwards and make sure they get feedback on them before they automate.

(IMO novice teams should be writing them down in the workshop for quick feedback while the BA is right there, but most people do seem to move beyond that.)

[Dan North]

Hi Stephen,

Early on in a project is when you know least about what you are doing, so the most effective thing you can do is to try to surface uncertainty and identify areas where you have blind spots. Getting people together from different backgrounds and with different perspectives is great for this, because you will have different blind spots and you can often discover one another’s gaps simply by discussing different aspects of the delivery.

What happens when you articulate the business goal or goals? How different is each person’s version of this? What does the domain look like? What technologies do you know about? What else might be out there that could help you? Who are the primary stakeholders for this work and who else will need to be involved? What are the organisational and process constraints, and can we do anything about them?

I call this type of session a Discovery Workshop. The "Three Amigos" session is only one type of discovery workshop, and is a relatively recent idea. The goal of this kind of session isn’t primarily to define acceptance criteria or scenarios, but by all means use these if they help you explore the gaps. Similarly you may come out with some technical exploratory work to do, or you might want to investigate some of the organisational challenges. Anything that will help drive down the uncertainty that will otherwise derail you later on.

Deliberate Discovery, and BDD, assumes the biggest impediment to progress will be all the things you didn’t know you didn’t know, which lead to all those “if only!” regrets at the end of the project. The goal of discovery workshops is to surface some of that earlier on, to give yourself a better chance of success.

Because of this I tend not to be prescriptive about what works. Some teams like idea-storming sessions, using something like de Bono’s Six Thinking Hats or Alan Cooper’s Persona Modelling. Others like building a Product-in-a-Box or creating storyboards like a movie narrative. Some teams use the personas to drive the acceptance criteria, which I particularly like.

Different techniques have different outputs, so don’t get too hung up on acceptance criteria or scenarios at this stage. You may even find that being overly prescriptive at the beginning means you miss out on some options that would have made things easier. As an alternative, Gojko Adzic's Impact Mapping is one approach for keeping options open.

Thanks,

Dan

—

Dan North

Dan North & Associates Ltd

+44 7580 099876

d...@dannorth.net

http://dannorth.net

@tastapod

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

[Stephen Kurlow]

Hi Liz,

I've seen that too so can relate to that particularly when it comes to a team gaining BDD experience.

I've seen either a dev write the scenarios after the workshop or a tester write them or they pair and write the first cut of them together. I've then seen either a dev write the glue code pairing with another dev writing the application code and they swap step by step. Other organisations I've seen they want a separation of duties and only want the tester to write the glue code and the dev write the application code. BA tends to be less involved in the activity of writing the scenarios but atleast reviews the first cut of them before automation and application code begin.

Can you share any practical tips on making those different combinations work more effectively?

Regards,

Stephen

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubsc...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

--

You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

--

You received this message because you are subscribed to a topic in the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/behaviordrivendevelopment/Hra7O4fas8Q/unsubscribe.

To unsubscribe from this group and all its topics, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Stephen Kurlow]

Hi Dan,

Thanks for your feedback.

The big take away here is to not be hung up on applying the 3 Amigos during the discovery activity? If teams already have another effective discovery method such as any of the ones you mention below then sure continue using it?

Regards,

Stephen

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

[Liz Keogh]

It will work differently in different organizations, but I do encourage organizations to allow devs to help testers or testers to help devs particularly. It doesn't make sense to me that a tester would be the only person able to write the glue code for scenarios.

For a start, glue code normally gets messy quickly and has to be refactored into nice page objects and different contexts, so having devs on board for that side of things is astonishingly helpful. Of course you would pair if possible.

When I use the term "BA", I mean "someone who can analyze that aspect of the business". So if you're writing security code, you would talk to a security expert; if architecture, an architect, etc. I don't necessarily see "BA" as a particular role, though there's nothing wrong with having someone proxy for your busy business stakeholders, as long as they're aware of the limitations of their ability to do so.

Testers have the awesome, evil power of breaking things. They're very good at spotting scenarios that are missed.

I prefer to see devs write the scenarios down, as we're "solution space" people. We have a tendency to jump to solutions with incomplete information (which you have to do as a dev; it's part of the job). If the devs write the scenarios down it gives the testers and BAs a chance to review their understanding.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Dan North]

On 28 Feb 2015, at 21:55, Stephen Kurlow <sku...@gmail.com> wrote:

Hi Dan,

Thanks for your feedback.

The big take away here is to not be hung up on applying the 3 Amigos during the discovery activity? If teams already have another effective discovery method such as any of the ones you mention below then sure continue using it?

Sure thing. As Liz says, the goal here is to start to create a shared understanding and to try to surface ambiguity, assumptions or any of the myriad other kinds of uncertainty and miscommunication. Anything that helps with that is a win!

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.