How we build a MVP in just 4-weeks!
Continuing with sharing of how we work in a lean and agile way, we’d like to now share how we develop a minimum viable product (MVP) for a mobile app in just 4-weeks. Before starting development of the MVP, we like to make sure everyone is on the same page on what will develop. Our Product Ideation and UX Design activities help with that (see earlier blogs: How we do Product Ideation in just 5-days! and How we do UX Design in only 7-days!).
One of the deliverables produced from these pre-requisite activities is a product roadmap. In the roadmap is the MVP, the initial set of features that we will develop and release for early use and product validation. Check out earlier blog on defining an MVP: MVP: How minimum is minimum?.
Development of the MVP kicks off with a 2-hour time-boxed planning session. Here, we discuss the features planned for the MVP, in particular, the capabilities and expected outcomes for each feature. A work schedule for the 4-week development effort, or Sprint, is set and serves as a baseline for progress tracking (burn-down). The first set of features to be developed are allocated and work commences.
On a daily basis, each member of the team reports on their progress and any hurdles they are facing. We walk the talk by being mobile ourselves and working remotely. Depending on the project and depending on the day, that might be working from home, at the customer location or a shared working space. This can make attending daily stand-ups tricky. To overcome this, we use Voxer. See our earlier blog on how we do this: Daily Scrums With Distributed Teams.
We supplement our daily stand-ups with regular 1-hour time-boxed customer progress review meetings where we essentially conduct a mini-Sprint Review, demonstrating whatever we are working on at that point in time. Depending on the project, we may do this multiple times per week and no less than once per week.
At the end of the 4-weeks, we hold a final 2-hour time-boxed Sprint Review meeting where whatever we had developed up to that point is demonstrated. This final demo is not much of a surprise to anyone, or should not be, since we had been holding mini-Sprint Reviews all throughout the Sprint. A decision is made to release the features (the MVP) or to do further work in another Sprint before releasing. More often than not, we challenge ourselves to find something to release over nothing at this point as it’s easy to succumb to 90% done syndrome and to polish.
We do a lesson learned round-table (Sprint Retrospective) typically at the end of the Sprint Review, while everyone is already gathered together (more out of convenience than anything else). This wraps up the 4-week development effort and positions us well for continuing working on the mobile app while benefiting from early insight gained from real-world usage of the MVP.
