Overview

Towards the end of 2018 I went to a workshop at Agile Leicester on Behaviour Driven Development (BDD) and Three Amigos. This article gives some references about where you can learn more about these techniques and then continues through the introduction of this technique to a team and the results that were achieved. I gave a talk back to the Agile Leicester community on this subject in early 2019 and the picture above is of that talk.

 

Motivation

The stories we were using were closer to contracts than stories

 

Research

I went to a workshop about BDD and Three Amigos at Agile Leicester given by Stuart Day.

Articles that summarise the practices:

• The behavior driven three amigos article
• BDD 101 Introducing BDD article

Refresh on what stories actually are:

• User Story Mapping – Jeff Patton
• User Stories Applied – Mike Cohn

Starting Point

• We were keen on using the brilliant minds of all the team members to create the vision and to be a part of creating the solution rather than developing exactly what was written.
• Our stories had lengthy acceptance criteria that weren’t focused on the user needs and stipulated exactly what the solution should be leaving no space for creativity.
• There was not enough room to question, influence, and negotiate in the stories.

 

Experiment Hypotheses

By using BDD and three amigos we would:

1. Focus our communications on the value to a user of a feature and the behaviours that would help us ultimately achieve that value
   1. This would support us in negotiating and sharing solution ideas, moving away from it being pre-decided
2. Spread the understanding of the story through the team and enable empowerment
   1. This would allow the team to make decisions on the solution with the Product Owner
3. In depth behaviour discussions would enable pragmatic approach to MVPe
   1. This would allow us to deliver smaller increments of working software to allow feedback

 

Method

To achieve our hypotheses we had to change how we worked.

Story Writing

• First thing to change was how we wrote stories. I worked with our Product Owner to refocus the stories back on what the User wanted and only that. No more design specifications, no more interaction specifications that a user doesn’t need to gain the value. We stripped them right back to CARD and CONFIRMATION all from the user’s point of view. (see Ron Jeffries explain CARD, CONFIRMATION, and CONVERSATION here -> https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/)

Three Amigos

• We changed how we talked through stories as a team. We previously had backlog refinement where the Product Owner would present to the team the stories and then we would move on when everyone understood.
• We started with four hour-long Three Amigos sessions per sprint to refine the stories ready for the next sprint.
• The team would decide who turned up from each specialty (i.e. who for the QA amigo and who for the Developer amigo) and the Product Owner would always be there, sometimes with a stakeholder if it made sense.

BDD

• We used the acceptance criteria as a guide to writing the scenarios as Stuart demonstrated in his talk. We talked through each user-driven acceptance criteria and created all the behaviour scenarios that supported that confirmation.

 

Results

1 Focus our communications on the value to a user of a feature and the behaviours that would help us ultimately achieve that value

• Changing how we wrote the stories brought the focus back to WHY we were developing the story in the first place and the unnecessary words were removed
• Our Product Owner has felt that these discussions help to marry the user need and the technical depth behind the behaviours
  • Originally this did take up more time for her as instead of just writing her story and presenting it out to the team she had to spend time creating it with the team
  • But previously a change to a story would be very time-consuming and this made it more tempting to resist the change. Now change happened naturally
  • Overall, time was saved

 

2 Spread the understanding of the story through the team and enable empowerment

• Collaboration with people of all different disciplines shone a light on different options and things that previously may not have been thought of
  • For example a QA amigo may think about all broader scenarios like ‘what should the behaviour be if…’
  • A developer amigo might be able to see that a solution is going to be slow and take a lot of power to achieve
• Existing behaviour was talked through to share knowledge of the product in general
  • When we started using BDD we only talked through the behaviour that would change with this story
  • We learned that omitting existing behaviour from our discussions was not the best approach as the team members who hadn’t touched that part of the product before didn’t know how this new story would impact what was already there
  • If we felt that the existing behaviour was something we needed to consider as part of the story then we created scenarios
• Talking through the language in the scenarios all together boosted our shared understanding
  • We had plenty of conversations about what certain words meant to make sure we were all using common language
  • We used our user roles to make the scenarios relatable, defined terms, and debated grammar
  • Some of this was too far admittedly and one of the things we learnt is to not waste time straying from the goal of three amigos on a quest for perfection

 

3 In depth behaviour discussions would enable pragmatic approach to MVPe

• By splitting stories into scenarios we could see a bit clearer on their size
  • For example if we found one had a lot of scenarios we could group them together and there our story was split by functionality just as simple as that.
  • Or we could cut some out that maybe weren’t vital to the user. These scenarios could come later.
• We did also learn that BDD scenarios don’t work for all types of features for example one with a specific, non-negotiable set of rules set by a regulator. Scenarios are good for in general what happens if a rule is followed or broken but not needed for the actual rules.

Close

All in all using BDD and Three Amigos achieved the three hypotheses that we set out to achieve. There are many more benefits cited from using this technique, including improvements to quality and documentation, but as we weren’t measuring ourselves against them I haven’t included it in this article.

It also goes to prove that Agile community events are wonderful places to learn and I am extremely grateful for them (hence the cheesy slide of my thanks in the header picture).

Extensions

To keep working with and improving. Will update with any new challenges or tips. Let me know how you have found using BDD and Three Amigos in the comments below.