Do you believe me if I tell you that I had the right receipt to refine User Stories? And what if this receipt helps you to have smaller stories that still deliver business value? And If I add that this receipt allows people with different seniority to create a shared understanding of the new features all together and having fun in the meanwhile? Believe it or not, I will tell you how my team was able to get these benefits adopting Example Mapping. It’s not something that happened from one day to the next one. But here I will share with you my learnings. It is up to you to bake the receipt as is, or to add your favourite flavours.
The beginning of my journey with BDD
Have you ever tried to apply Behaviour-Driver-Development (BDD) and struggled on the effectiveness of the three amigos meetings? I personally got interested in the principles of BDD from the first moment that I heard about it. But to be honest, at the beginning I was quite frustrated by the small amount of scenarios written in these meetings where as developer I was collaborating with the requirement engineers and the testers. OK… the conversations and the collaboration among us were useful and interesting. But, the price in terms of hours spent attending these meetings was definitely high. Here, I’m completely transparent and I admit that in the very beginning I was not a big enthusiast of writing the test scenarios with gherkin syntax. Long before my incorporation to my team, they were already proficient with SpecFlow, the open source port of Cucumber in .Net. Personally, I was feeling that gherkin was adding an abstraction, making the tested reality more opaque. And I still have the same opinion. But now I firmly believe that this abstraction is a price that is worth to be paid. What changed my mind? I have no doubt: the journey I had with Example Mapping. Infact, the adoption of this technique together with the usage of gherkin really leveraged the way my team was doing BDD to a new level.
A Brief Introduction to Example Mapping
I don’t want to describe Example Mapping too extensively. Although it is a technique relatively recents, you can find a lot of good references about it. I can suggest my personal selection at the end of the post. For example, you can start from the post where the creator of Example Mapping, Matt Wynne, introduced this new agile technique in 2015 1. Aslak Hellesøy published a well done introduction 2, if you prefer to see a more hands on introduction. At the very end, Example Mapping is a structured way to improve refinement and BDD. It’s an evolution of the three amigos meetings. Its structure helps to have shorter conversations, but at the same time to make them extremely more powerful and productive. How? It’s simple. The business expert brings to the session a user story that is composed by several rules. For each rule, the business expert already brings some examples to help clarify the feature and to trigger the conversations. In fact, at this point all the attendants will start making questions and providing more examples for each rule. Gaspar Nagy in his post3 explains very well how this process helps to exploit all the hidden aspects of a feature. Typically people in the room start challenging data and preconditions of the examples. Apart from the happy cases, they also provide the rainy cases. People ask about other possible outcomes associated with the actions performed in the examples. However, don’t get confused! Example Mapping is not simply a factory generating test scenarios. The real benefit of its usage is the conversation generated in the creation of these new examples. Infact, creating concrete examples helps to clarify the problem and encourages conversations among people. So, people raise questions that no one has yet answered. And this is totally fine! If you have an unanswered question, you park it in a red post-it and someone has some homeworks to do before the next session. But do you know the good news? You just kick away an unkown unkown in the known unknown area.
Slicing the Elephant
Have you ever heard the expression carpaccio elephant? The first time I heard this expression, it triggered in me a mix of laughing and horror at the same time4. However, I think it is a powerful metaphor and it suits very well what happens when doing Example Mapping. As far as you exploit one rule of a story, it can happen that you start having too many examples associated with it. This is a sign that the rule should be splitted in order to have simpler ones. Moreover, when you have too many rules associated with a story, you know… the story is too big. Then, at this point you can split the story into smaller ones. So, now you have a tool that helps you to have small chunks of work that can slide in your iteration without inconvenience. The big advantages that each of this story will still bring business value with them. Infact the split has not been done following antipatterns like performing implementation in a story and integration testing in another. You have now a small shippable increment of business value at each iteration. Thanks to Example Mapping, my team was able to create a rule of thumbs that correlate the size of the story with the number of rules and examples of the stories. As a result, we moved away from estimation in story points and we adopted a no estimates approach. However, this is something deserving of a post itself. Stay tuned!
Have Fun: Focus on the Conversation Not on the Gherkin
I cannot stress more: the goal of Example mapping are the conversations not the test scenarios. Don’t get lost writing the gherkin. Don’t be picky writing the example! My team learnt this lesson the hard way. We wasted a couple of sessions being too strict with the syntax. And more dangerous, we almost lost people’s engagement with the technique. Have fun! You need to spend a lot of time sit together in a room. Moreover, these sessions are extremely expensive: an entire team in a meeting means the tachograph is running fast.. So, you should prioritize understanding the feature over writing the BDD scenarios. In our case, during the session we just write simple post-its like the ones in the figure. We state the preconditions, the action and the expected result. Then, in a second moment, our product owner writes the scenarios from the examples using gherkin. However, I’m more with Matt Wine advice, that suggests that the gherkin is written by the team after the session. In this way, the product owner reviewing the scenarios can also ensure that the team has really understood the stories and can give feedback.
Fighting the Hero Driven Development
Have you ever sat in a refinement session where most of the conversation is led by one or two senior developers while the rest of the team is listening passively? For me this is a clear alarm bell. It is alerting you that your team is suffering Hero Driven Development 5. Example Mapping is a tool that can help you to mitigate this risk. Before starting Example Mapping sessions, I like to make clear that we are acting in a safe environment and there are are no stupid questions. In these sessions, one question follows another one with a good vibe. Very soon, all people in the room are involved in the conversations. And also junior and less experienced people make questions and create examples. I usually can feel an important difference in the juniors’ participation between refinement sessions and example mapping. Definitely they are more involved in the example mapping. This is a big help when the feature enters the development phase, because the team will already have collective understanding and ownership of the solution.
To be continued…
Now, you can understand why at the beginning of the post I was so enthusiastic about Example Mapping. And while writing this post, I realized how much my team evolved and improved in the usage of this technique. I want to share with you more of these learnings. But, listening the wise advices of Monica Lent course #bloggingfordevs 6, I neither want to write here a magnum opus. So, in the next post I’ll provide a set of tips and tricks that my team learnt during his journey with Example Mapping. For example, how we get the most from the physical setup and how we evolved with the right remote environment. So, if you have curiosity about how we use it or you want to know in more detail some aspects, just drop me a comment or send me a message. I’ll be more than happy to engage with you and eventually cover your points in the next post.
Useful Links
-
Introducing Example Mapping: https://cucumber.io/blog/bdd/example-mapping-introduction/ ↩
-
Introducing Example Mapping by Aslak Hellesøy: https://www.youtube.com/watch?v=VwvrGfWmG_U ↩
-
5 tips to avoid forgotten requirements by Gaspar Nagy: http://gasparnagy.com/2019/04/example-mapping-5-tips-to-avoid-forgotten-requirements/ ↩
-
Elephant Carpaccio: http://www.agileadventures.net/index.php/2015/09/27/elephant-carpaccio/ ↩
-
Anti-Pattern, Hero-Driven Development: https://scrumisscrum.wordpress.com/2009/04/02/hero-driven-development/ ↩
-
Learn to grow your blog as a developer: https://bloggingfordevs.com/ ↩