Process
The Elusive MVP
Minimum Viable Product, commonly abbreviated to MVP is a term almost everyone working in software is familiar with (or should be). It’s something everyone starting an application from scratch sets out with the intent to build though very rarely is actually achieved.
The reasons are numerous and usually come so naturally that you don’t even realize that you’ve slipped into the feature bloat abyss before it is too late. Some of the more common reasons I’ve seen and fallen victim to myself are:
Keeping up with zuckerbergs: Facebook has this cool thing, Pinterest has this neat widget, Amazon does this other thing, my competitor has this feature, and we should do it too!
The ever-moving finish line: Features cannot be delivered faster than new ones are placed into scope.
Fear of completion: This is my life’s work and dream, I’ve been planning it for years and I don’t want anyone to see it until everything is perfect.
It’s an Epic journey
At Hashrocket most clients who walk through our door already have heard the term “Minimum Viable Product” and believe that the feature sets they have in mind are truly their MVP. Once we sit down and start learning their domain and talking through the workflows and roles in the system we typically find that in reality the expectation is anything but an MVP. In most cases clients want an application that is bigger than their budget. It is our job to make sure every story-card is in support of a feature that works towards allowing users of the system to achieve a core business value.
The first day of story-carding we identify what the app is supposed to do, what’s the itch it is scratching. Once we know what the goal of the application is we capture the core feature sets needed to achieve that goal in one-line epics. We then talk through each of those epics capturing the individual stories required to complete them. When we identify a “risky” type of interaction we collaborate to determine the simplest solution that still achieves the goal of the feature. Many times we will write the cards both around the simple solution as well as the riskier interaction, tagging the riskier interaction as “Enhancement” or “Nice to have”. This allows us to help the client spend their budget on the items that are core to their MVP deferring superfluous scope until after launch.
As an example, if we were building a simple online bookstore we might have core business value stories defined as:
- User browses through books
- User searches books
- User purchases a book
Each of these “epics” would have a number of child stories which enumerate through the functionality needed to complete that epic. The ‘epic‘ feature in Pivotal Tracker makes this easy to organize and manage.
Can I supersize that?
During story-carding, discussion may turn to providing the ability to add books to favorites, rate books, review books, etc. We make it clear to clients that we will challenge them on scope that does not directly work towards achieving the core business goals of the application. Given this domain the aforementioned features are the type that we would typically push back on. Depending on how important these stories are to the client we will either defer the writing of these stories to later, or write the story under a separate epic. When we work with the client to prioritize the stories, those stories can be quickly identified and ordered after the launch release if the client so chooses. We are sure to remind the client that those stories may or may not get done depending on how rapidly we progress through the backlog. It forces the client to come to the realization that they may not have the budget for everything they want, but also introduces them to prioritization.
About that finish line
We always tell clients that our goal is to get them to a feature complete product as fast as possible, meaning users can perform every action they need on the site to complete the goal of the system. We can then build upon that foundation incrementally in their desired order knowing that we can stop work at any point and they will have a completed application. The last thing we want is for a client’s budget to be consumed and they only have a 75% complete application. Best case scenario, we get to feature completeness well before a client’s expected budget is consumed and then they can make the decision of whether they want to continue development with enhancements to core features or go get user feedback and do the due diligence in truly tailoring the application to their users’ needs.