At Bornfight, we started using Behavior Driven Development on our projects, about six months ago. From the very beginning, every member of the project team could see the benefit of using BDD. However, it can sometimes be hard to get everyone on board, especially when it comes to having all the project members to talk about features/BDD stories. And if we are not collaborating and not talking about the features, we can not get a shared understanding of the features. If we do not get a shared understanding, we are not doing BDD!

Solution

To overcome this obstacle and to see the true value of collaboration and shared understanding, on one of our sprint retrospective meetings, we decided to play BDD - Shared Understanding game.

The game is very easy to play, but the benefits are far greater. Basically, we needed one person to make some basic drawing (designer) and the other person (project manager) to look at the drawing and take a note (acceptance criteria). After taking a note, the project manager handed us the acceptance criteria and without showing us the drawing asked us to draw it down. We were two backend developers, one fronted developer, a software tester, and another designer.

These were the acceptance criteria:

• A large empty circle is located above the horizontal half of the frame, closer to the middle.
• In a large empty circle, a little above and a little to the right of the middle there is a small filled circle.
• In the plane with a small circle there are 2 small filled circles, one next to the other, but outside the large circle.
• The left small circle outside the circle is shaded.
• Parallel to the small circle inside the large circle, above, at the top of the frame, there is another small circle that is slightly smaller than the small circles inside the large circle.
• 2 straight lines are drawn from the middle of a large empty circle, one goes straight down to the bottom - a parallel line, and the other, horizontal line, goes to the edge of the left frame. (Feel free to try it yourself before looking at our results.)

The original was drawn in Figma by one of our designers but the rest of the team could use whatever preferred, Figma or pen and the paper.

Results

This was the original drawing:

And this is how each member of the team perceived by following only the acceptance criteria:

After seeing the original and then seeing each other's drawings we were amazed how everyone understood, the same text, differently. And this was our conclusion:

• A picture is worth a thousand words.
• It is very important to write clear and accurate acceptance criteria.
• It is important to build a common language.
• We drew some things based on the assumption and some of them were correct by pure luck.
• It is important to revise the acceptance criteria together.
• We all think differently and perceive what we read differently.
• Different perspectives are not bad. They give us a broader picture and new ideas.
• The most important thing is to gain a shared understanding.

So if you work on complex software, when you get the acceptance criteria, talk it through with your project team and make sure that everyone understood it correctly. Otherwise, you can end up dealing with a lot of bugs or even worse, with useless software.

Feel free to contact us if you need help or you'd like to discuss Behavior Driven Development concepts.