Member-only story
Going from User Story to finished prototype in one week

Building an application is like a marathon; building each feature is like a sprint.
The goal of each sprint to pick one or more features (user stories) to work on. Ideally, the feature should be able to be an application on its own. For example, a user story for a budgeting app could be:
As a new user, I want to set up my budgeting profile
If we develop only this feature, a user should be able to open this application and set up their profile (e.g starting cash, income, expenses etc.). At this point, the application will do nothing else, but it will take a new user’s information down, make sure it’s valid input, and have that data ready for whatever feature you build next.
When you finish each sprint, it’s like having another Lego piece, until you complete enough sprints to build your MVP (minimum viable product).
Each Sprint comes in three stages:
1 — The Sprint planning
2 — The Sprint
3 — The Spring Retrospective.
Sprint Planning
Before the sprint can start, double-check that each user story you’ve chosen to work on fits the INVEST method from Part I.
As discussed in Part I, the user flow diagram is a rough sketch that helps us create our user stories. During the sprint, we will turn the user flow we made into an actual wireframe, then polish it up to make it a prototype. But before we begin that process, we need to refine our estimate and create acceptance criteria.

Estimating
When you were creating your user stories, you loosely estimated how long you can build a prototype for each story. This is the time to refine that estimate. The first few sprints will be hard, if not impossible, to estimate accurately until you get adjusted to the work involved. However, your estimates become more precise after each sprint, until you get to a point where you can accurately estimate how long the rest of the application will take.