However, it can sometimes be hard to get everyone on board, especially when it comes to having all the project members 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. And if we do not get a shared understanding, we are not doing BDD!
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 huge. Basically, we needed one person (designer) to make a basic drawing 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, a 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 they preferred – Figma or pen and paper.
This was the original drawing:
And this is how each member of the team perceived it 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!