DEV Community

loading...
Cover image for Defining the MVP

Defining the MVP

Martin Emmert
πŸ‘¨πŸ»β€πŸ’» Freelance Frontend Engineer πŸ“· Hobby Photographer, πŸ‹οΈβ€β™‚οΈ Crossfit & πŸƒπŸ»β€β™‚οΈ Jogging πŸ•Ή Developing a #indiegame using web technologies
・3 min read

Starting a new project on Github, creating a new app with CRA, pushing your first commits, see the CI pipeline running and publishing your application feels great. Staying productive, making progress, keeping the focus after the first lines of code have been written, is also something that makes projects fun. Planning a few steps helps to achieve exactly that. Not every detail of each feature has to be laid out perfectly. Use the planning phase to draw rough sketches of what needs to be done. Go into details while being at it and do not put yourself into tight constraints upfront.

Describing the features of your app by using user stories does exactly that. It puts the focus on the what and postpones the how until the feature will be implemented.

It is often not easy to find abstract enough formulations to describe features, which are already floating around as implementation details in your head. Take your time and do not overcomplicate them. A change of the space around you (context) may be helpful, too.

The following template is often used to keep them in the same format.

As a <type of user>, I want <some goal> so that <some reason>.

To be fair; as I am sitting here, writing this post, I am also eager to get started already and skip the planning phase. But in the end, I also know that this process helps me building this application.


Some words of advice on shaping an MVP:

Do not wait until feature XY is ready, feature ABC reached a stable state and Max polished the designs for weeks.

The first impression counts and mostly it's the only chance given by most users. But if the first impression is postponed until the product is ready by your definition, you will miss out on the chance of getting valuable feedback of users that see something in your product and want to help to shape it.

I'll try to release something after each feature is implemented. Until the product is meant for production, stuff can and will break, data is lost and ideas change.


Finally, here are the user stories I'd like to implement first:

As a user, I want to write down my thoughts in a bullet list so that I can see them all in one place.

As a user, I want to organize my bullet points in a hierarchy so that I can create a meaningful order of my thoughts.

As a user, I want to freely move my bullet points within my list so that I don't have to think about any order while writing them down.

As a user, I want to delete any of my written down bullet points so that I can keep only what is meaningful to me.


You can find the user stories on the board of my Github project.

As I said earlier, I don't go into that much detail upfront and like to keep them short. As a Team, you normally would define subtasks and delimitations for each user story to split the work into smaller chunks. Doing that helps to share the work in a team.

Working solo on a project makes this an overhead, that I tend to skip ;-)


Cover Photo by Halacious on Unsplash

Discussion (0)