Specification by Example - What is that?

Another project management method and again an term, under which one can imagine something vaguely, but with which it surely does not hurt to read up again more exactly, what it actually is: Specification by Example. 
This technique is about detailing requirements in two directions. One of the two predefined directions is communication with the customer - or, depending on the project, the various stakeholders, as well as communication with the developers. The other direction is testing. Specification by Example is often mentioned in the same breath as the Job Stories method. So what are the differences and what are the advantages of the Specification by Example technique?

The basic theme of this method is the tasks and challenges that are to be identified through user stories, and then to avoid misunderstandings and mistakes in this area. Often teams are constantly busy trying to fix problems caused by unclear requirements which lead to misconceptions. The classic approach here is to use user stories.
 
Use acceptance criteria and follow the five basic principles:
 

The most important advantage of this method is certainly that it is an invaluable tool for almost completely eliminating misunderstandings at a very early stage. If you proceed according to the specifications of Specification by Example, you exercise a user story from beginning to end - and this on a very concrete example. There are no abstract ideas or goal formulations that need to be interpreted, just the example that is used to pursue the goal that comes from the user story. This example gives you an acceptance criterion, which you then in turn coordinate with the stakeholders or users. Misunderstandings are identified early on, and you save an enormous amount of time by not even starting throughputs and development processes that do not lead to the desired goal. By playing through examples, the requirement becomes clearer, and the behavior of the respective requirement can also be recognized and described in different characteristics. If you always proceed according to a previously mutually agreed structure, your acceptance criteria will be uniform and can be described particularly well.

Proceed according to the so-called Gherkin scheme. This scheme in combination with Specification by Example describes the basic framework of the respective user story. The user formulates (with your help) concrete acceptance criteria: An action is taken on the initial state and finally a result is achieved. Now this seems very theoretical, it may not be immediately obvious why this extra step is necessary. But when all acceptance criteria are listed according to this scheme, a rhythm is created that allows you to work more closely and error-free with users. It is an approach that is also followed, for example, by the Daily Stand Up Meetings in Scrum. Daily, same time, same place, same process. If you manage to also organize your user stories in such a way that acceptance criteria that are accepted by everyone are developed by continuously and systematically working through examples, you will have taken a huge step towards success.

Now the testers come into play: They will be able to work faster and better with the acceptance criteria determined and logged in this way. Tests can be excellently automated on the basis of the criteria. Constant rewriting is eliminated or reduced to a minimum, which in turn saves time in this phase. In addition, this approach makes it possible to do the tests before the codes are written. This is simply called a test-first approach, and it really just means that automated tests are written based on the acceptance criteria, and only then is the code written. Quality standards can be significantly increased by this approach.

So, is Specification by Example or the Job Stories approach the better alternative? Here opinions differ and in the end it is a matter of taste and preference. Some work well with Specification by Example, others prefer Job Stories. Basically, both methods pursue the same goal, and they are both promising. Job Stories may have the small advantage of focusing on customer satisfaction and the emphasis on defining and working through the jobs to be done. Many companies use Job Stories whenever they feel that the development teams have strayed too far from the customers and what they want. In the end, though, it's really a matter of habit, because a well-coordinated team can use either method to achieve success. Companies that already have the desired closeness to the customer often choose Specification by Example and in this way focus less on customer collaboration, which after all already works well, and instead focus on improving processes and streamlining testing.