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…
- to identify weaknesses in IT-support and cooperation.
- to visualize how the domain will change because of the software being developed.
- 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.”