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.

Getting to know the backlog

A backlog is a priority list with all of the features listed. People that can’t code or don’t have experience in the development environment, will struggle to write these, but they are essential and a major component of agile app development.

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, leading to much longer times to develop, higher chance of risk, and many other negative impacts.

Once that first meeting is done, the product owner takes the details discussed and creates a general outline of what is needed. Backlogs are written in a specific way. In the picture, you can see our version of this. There is a Theme, Short Description and then a user story sentence structured as follows: “As a(n) _______, I want to ______, in order to______.” This first draft general backlog won’t be a perfect blueprint of the future of your app, but it will give you great insight into the size of the tasks, how long it will take, and what is truly important enough to implement in an effort to begin to turn user engagement into revenue for your startup or business.

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

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

Once this general backlog is created, the rest of the team, most importantly development, give their insight into the items and help to completely break down the general backlog items into “irreducible” (can’t break down further) backlog items. This allows the sprints to be very accurately planned and executed in the near-future. Once the backlog is internalized and the team is in agreement that all the items are present and, most importantly, completely broken down into irreducible backlog items, it’s now time for the first meeting, the Sprint review meeting.

Contrary to the Statement of Work or other Waterfall documents, the backlog is never “done”, just like an app. When bugs pop up out of nowhere, new features are needed by users, revenue is needed and a pivot happens, Google or Apple update their software and create conflicts, or any other number of variables that come up in software development pretty regularly, the backlog gets new items describing them and those new items get fit into the plans made before the issue arose to keep development moving at a consistent pace. In this way, the backlog is a living document that keeps only the most important things being developed at any given time.

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. Lack of the backlog’s level of specificity is why. They do not use this level of granularity, so they can’t know all of the little times 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.