The people involved in requirements elicitation have to learn and to communicate continuously. If you have read the “Quick-start Guide”, you saw how Domain Storytelling helps to learn domain language and to reach a shared understanding. If you are a product owner, domain expert, business analyst, or developer who has to deal with requirements, you can use Domain Storytelling…

  1. to identify weaknesses in IT-support and cooperation.
  2. to visualize how the domain will change because of the software being developed.
  3. as a starting point for writing down requirements.

Domain stories help to initially fill a product backlog with epics and user stories. The user stories can usually be derived directly from the domain stories. For example, earlier we recorded a domain story about making ticket reservations. We have learned that when a customer reserves tickets on site, the cashier opens the screen plan for the show and offers seats. From that, we can derive a high-level user story (without acceptance criteria): “As a cashier, I want to determine the free seats for a show so that I can offer these seats to my customers.”