7 Day Mobile App: Build v0.9

In our overview of How to Build a Mobile App in 7 Days we explained our high-level process:

1) Define & Design

2) Architect

3) Build v0.8 and get client feedback

4) Finish v0.9 and test

5) Deliver the final app and Celebrate!


 

The goal of Step 4: Build v0.9 is to build the feature complete app that we have designed and architected in the first steps. We made the tough decisions and already built the heart of the app – focusing on the riskiest technological pieces first. Now we need to make the app feature-complete, integrate any feedback from the client, and do a few passes on the look and feel of the app.

While the client is reviewing v0.8 from the previous step, our team is pressing ahead with the rest of the features that we know we haven’t yet delivered. We also usually take this time to get a good night’s sleep so we’re feeling fresh for the remaining 2 or so days of the sprint.

We use tools to help us collect feedback from the client both directly and automatically. Twitter’s Fabric portfolio of tools is great for automatic crash reporting (this tool used to be called Crashlytics). When anyone crashes the app, the entire team is instantly notified via Slack and a new Asana task is created.

We also use a few tools to help collect more intentional feedback from the client. One of our tools allows the client to shake their device and file a bug or general feedback, along with a screenshot, a quick drawing, and a comment. This is really helpful for allowing our developers to reproduce bugs quickly so that they can tackle them. These items are also plugged straight into Asana and Slack for the team to see in real-time.

Once the client returns with feedback, our PM and Senior Developer join forces to translate the crashes, feature requests, major bug, and any other internal or external feedback into actionable development tasks and then prioritize them. This is the final chance to add in any tweaks or changes. After we compile and execute on this list, we will only accept bugs as new tasks.

This brief definition and re-prioritization of tasks is one of the last times we are in decision making, “smart-brain” mode. After that we hop back into code monkey mode (“dumb brain”) and focus on development.

After we handle all of these tasks, we ship v0.9 and really dive into QA in preparation for the final release.