We take initiative and ask for forgiveness instead of permission.
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).
Wireframes
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.
Estimation
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.
