Planning your MVP

Part 2 in the What to expect when developing an app for your startup or business series

So you have what you need and a team you trust to implement it. What do you do next? The most important next step is to begin the living document called the backlog and draw some cut-lines. During the very first meeting (before the first Sprint Review meeting), the team sits down to go over what is most important in the app and start to define a rough draft of items they would like to see in the first (MVP) through later sprints.

What is an MVP?

Minimum Viable Product is the Most Valuable Piece of the app

When you are building an app, you don’t just go with an idea to development, wait some time, then get back a finished product. That is called waterfall development and doesn’t work. The way apps are built is through an agile, iterative process. This takes a kernel of an idea (a hypothesis really) to fix a problem for people at their business or elsewhere in the case of a startup. The kernel of the idea is the MVP or your minimum viable product.

If you search for Minimum Viable Product, you will find an numerous definitions and ideas of what an MVP is. You can put up a landing page, create an interactive mock-up, or other non-code things. However, this isn’t the actual (code driven) app and that is what we call MVP, so we will go with that definition.

The first step toward your MVP is to devise what it is. This is when the question, “what is your unique value proposition” comes in very handy. Your unique value has with it the core value you are offering to users. From that, you can, with experienced partners in best practice, brainstorm the best way to get a test into the hands of users. If your unique experience depends on someone sharing information with another person, do that in the least complicated way as your MVP. If your app requires people to use GPS and see other users, go with that as your MVP and see if people use it. If they do, you’ll know to build more. If they don’t like it, you’ll know a direction to go from there thanks to their feedback. All of this becomes an iterative process that never ends. So, you need some way to manage the could-be cluttered mess of ideas, feedback, bugs, etc..

Getting to know the backlog

The backlog is the tool agile prescribes for prioritizing the app’s development. When the first meeting happens, it is very common to have a very large vision about how the app will please users. However, this view of the app in the early stages has the issues waterfall development does in specifying the functionality needed by your specific app, to the granular detail needed by the implementation team. This leads to much longer times to develop, higher chance of mismatch in vision, and many other negative impacts that will cause major delays and higher costs (in time and money). The issue is, these backlogs can become cluttered and are difficult to read, there isn’t even one set way to implement it. Therefore, Blast Off Apps has taken the initiative to demystify the process and make it accessible to anyone, no matter how little they are familiar with technology. It’s a tool that makes it easy for anyone to understand and manipulate this technical tool that is the backbone of the industry standard methods. The backlog is re-invented as a way to measure progress in your project’s development with complete transparency and control over it’s mission plan.

Introducing Mercury by Blast Off Apps

see a video walk-through here

Planned Features

The place new requests are put is the Planned Features column of Mercury. It is here that items are created by our team and tools to give you insight into the requirements for your app at any given time during development.

This is our take on the backlog combined with a transparent platform to see and control the progress of your app’s development like nowhere else. Mercury is used throughout development and just as a backlog acts as a priority list containing all the possible features of your app the Planned Features column houses all the possible features. You can even move items in this list to re-prioritize your app’s future offerings, complete with cut-lines for better management..

Once set-up through our general item creation (quote) tool or our team helping you, you will see a number of short descriptions of items that need developed or implemented. In our full service membership, the product owner will break down the initial general backlog items into the granular structure required by development to develop your app as lean as possible. This helps keep the project on time and predictable to truly implement agile practices even if you aren’t a technical person.

The Planned Features column is also divided into “sprints”. You can add a sprint by hitting the “+” in the upper right corner of the column or asking your representative to help you in general chat. By assigning sprint lines, you can set a course to develop your app by parceling out the number of hours your team wishes to implement based on urgency, price, and any factor weighing on your decisions to move forward and commit items for development. You can click and drag on any of the sprint lines to move all of those items above or below others.

You aren’t left alone either, you can talk with Mission command anytime you like and your representative with help walk you through the process. Should you choose to move forward with development, you will have access to our team and they will work with you to create a plan of development that has years of experience baked into it along with close consultation to always keep your team’s vision in the captain’s chair, but having confidence in hitting the milestones needed to keep pace in today’s world

Item Details

The user story on this card reads like this from left to right:

“As a user, I want to have an editable profile that consists only of my name and a short description (image included if picture upload also selected) in order to let my connections know it is my profile.”

By clicking on any item in the Planned features column, you can bring up the item details. It is here that everyone on the team can see the full requirements, complete with the agile practices that are industry standard and lead to a much greater understanding of the individual needs of the app. Also, you can see or write comments that are specific to that item.

On the top left of this item detail shows the rank it is in your app’s priority list as well as how many hours it is and the description seen on the main dashboard. Below that, you will see a theme, a short description, and what is called a “user story”. This user story is the most important detail on this view of an item.

These user stories are structured in a specific way and look like this: “As a(n) _______, I want to ______, in order to______.” For example, in the example item in the image, the user story reads from left to right: “As a user, I want to have an editable profile that consists only of my name and a short description (image included if picture upload also selected) in order to let my connections know it is my profile.” Structuring all the items in this way gives a consistent way of communicating that helps drive down misunderstandings and is focused on the user. This user-centric nature of agile development is one of the major reasons agile development has been taken to by so many successful software projects and companies.

At the bottom of this item detail, any comments for the team will be present. You simply add your text and picture (if needed) and click “add” that will add your comment to the item and allow everyone to see the intricacies and decisions needed for any particular item in your main dashboard.

Requested Features

Anyone of those sprints from Planned Features can be dragged into the Requested Features column. By doing this, you can decide what exactly is being developed. This is the final staging area for sprints, nothing has been committed yet, but it helps show the highest of priority items and their total hour count at the bottom. You are also given complete control by allowing you to pay directly from the button at the bottom of this column.

In an active development environment, priorities can change very quickly. Causes range from feature requests from users, to new business demands, and even 3rd party updates to places such as Apple, Android, or other 3rd party software your app depends on. Mercury gives you that control and keeps our team in tight communication with you via your representative or your team of experts should you opt for only our $495 or $795 option to get the expert help you need. No matter the level of your commitment with Blast Off Apps, this platform allows you and your full team from sales, product, and business, to the development team to always be clear about what is most important and going to be coming up in the next sprint.

Confirming development of a sprint is as easy as clicking “Pay & Launch Development”. Our payment system is very simple and secure. Once you are sure your sprint is what you want, just click pay, fill out the simple fields and submit payment. Once the payment is successful, the items will automatically commit to development by being placed in the “In Development” column. From there, our team will spring into action and conduct due diligence and see to the development of your app.

The items will then move through the development process, being updated throughout and when they are finished, they are placed in the “In Test” column to indicate they are finished, but pending tests by the team. In our full membership, we use our team, tools, and yours to test as much as is required.

Once all items are through the process, the sprint is finished and the process reverts to the Planned Features column to decide which sprint is next in line. This iterative process separates agile and gives your team the ability to react quickly and on your budget, easily with no technical knowledge required.

Blast Off Apps creates a general backlog for you, FREE!

Contact us to see what your app looks like in a general backlog

If you’ve recieved any quotes in a waterfall system (most outsourcing firms), you will find they vary greatly in price and time to develop. A lack of the backlog or specification’s level of specificity is why. They do not use this level of granularity, so they can’t know all of the little items that will need sorted out in a giant statement of work or some other spec written by a non-technical person leading them to be incentivized to pad their estimates more than an agile team will.

In fact, agile teams are aligned 180 degrees differently. An agile team is vested in the idea, the user’s value, and completing sprints in a timely manner to continue in the process of making the app a success. When you are given a granular level assessment devised by the team together (with you), there is no need to pad estimates, the items are clearly stated and there is no “wiggle room”. Therefore, both sides are incentivized to get to the next sprint, not to get to an end of contract. This is why Blast Off Apps chose a completely customer facing agile development system, it puts a non-technical person such as yourself in the driver’s seat, giving you the added benefit of industry experts working on your side to leverage their knowledge and experience with your enthusiasm and insight into your market. Agile development is great at bringing value early and often to users by focusing solely on what is going in the app is only the most important as judged by the full team.

What’s Next?

Ok, we now have our cut-lines drawn and a good plan to move forward, what’s next? In the next part in the series we will discuss what you can expect from the development cycle starting with the Sprint Review meeting where you finalize your plans and move them to the implementation team for development..They make them technically proficient, add “acceptance criteria” and the development representative leads development based on the shared experiences they’ve had in the planning up to this point.