Main Course

Story Mapping

A story mapping session organizes the discussion about the user’s experience with your product. The resulting story maps arrange user stories in two-dimensional models to help understand the functionality of the product, identify omissions in your Product Backlog, and effectively prioritize and plan valuable releases. It is a way to tell the whole story in order to find the parts that matter most. We use story mapping to help find the way to minimize output (functionality, work) and maximize outcome (impact, value).


The use of wireframes significantly increases the chance that different people are talking about the same things. A wireframe is a sketch of a user interface. Wireframes lack typographic style, color, or graphics, since the main focus lies in functionality, behavior, and content. In other words, it focuses on what a screen should do, not on how it should look.

User Stories

User Stories are written from the perspective of the end user (Persona) of the product (as if the product can already be used like that). Telling the story is key here, not just writing it down. As part of our co-preparation[1], writing down user stories is done by the Product Owner and the team right after a Story Mapping session, in order to record the user stories told and discussed during that session. As part of the initial co-preparation of the project, the resulting user stories will be more rough than when co-preparation is repeated during the project for specific epics.


Product Development is a creative process executed once, preferably with an exploratory approach. This makes it impossible to do an accurate prediction of required time and costs. On the other hand the customer needs to know what is realistic, and have an idea on what budget is needed. Based on the experience of Kabisa with other projects an estimate of the budget can be made. The team delivers estimations for this, based on all information they got, being involved in the co-preparation sessions with the key stakeholders and the Product Owner[2]. Epics and user stories are first estimated on a relative scale (using Planning Poker). The clearest parts are then estimated in hours, days or sprints. Combining these two approaches (i.e. extrapolating) gives the best estimates the team can give in this early phase. Based on these estimates, a budget is identified. We strive for a budget that should be enough to at least build and deliver a Minimal Viable Product, and usually a few iterations on top of that. Estimations are used by the Product Owner for planning and tracking progress and making decisions during the project. This will help to scope an Epic[3] or User Story[4] with the team.


  1. Co-preparation - The Product Owner (PO) meets the Team with their technical skills to define the best solution for the business case challenges. Best ideas arise in offsite meeting(s) in a relaxed and inspiring atmosphere. Various techniques are used to explore possibilities and to discover business values and ways to mitigate risks.
  2. Product Owner - The Product Owner plays a crucial role in the development of a great software product. He or she is responsilble for maintaining the Product Backlog.
  3. Epic - An epic is a means to describe a larger user goal or business goal, that will be further developed in multiple user stories. Linking the user stories to the epic, gives insight in the context and progress of the epic. Epics are used to make a high level planning.
  4. User Story - A user story describes a functional goal from the perspective of an end-user. Who wants to do what with the product, and why?