Android Friday: Estimating app projects

Two weeks ago I wrote about tactics for estimating software projects. Let’s apply that to native app projects. These are some techniques I have used to estimate Android work.

Find your bearings

The first steps are obvious, and similar to any other software project. Talk to involved stakeholders and designers. Become clear on who the target users are. Try to understand the business domain and the problem you are trying to solve. Ask a lot of questions.

Factors that drive complexity in app projects

Now, dig into the standard assumptions and constraints of app development work. These factors have a dramatic effect on the amount of work required. Some of the most common factors include:

How is the app designed? Is the whole thing wireframed and thought through by the designer, or are there many unknowns? Is it a straight port of an iOS project? Is the designer comfortable with the Android platform? Is there even a designer available?
Will the design of the project stick to standard components and platform guidelines? Or are you looking at a custom user experience where you will need to build custom UI components?
What is the general level of polish needed for the first version? Is it an internal business tool that can be a bit rough around the edges? An exploratory MVP project for a startup? Or is it a one-shot where you need to ship a very tight, polished user experience right off the bat?
If the app depends on a backend, is the API already built, deployed and tested? Or will you and the backend developers chisel it out together along the way?
Does the project call for an app that handles offline mode well — or at all? A stateless app that only works on an active data connection is simple. Staying completely functional offline and sync everything up cleverly when online again? Much more work. Pick your battles wisely.
Does the project need to support tablets? If you scale every screen gracefully to tablet screen sizes it will drive up the time spent building the UI layouts.
How about landscape mode? Does the UI gain anything by allowing rotation to landscape mode? Will the designer even have time to take this into consideration? Otherwise, lock orientation to portrait mode to scope down the work.
How old versions of the OS does the project need to support? Try to dig up local statistics for the target user group. For an Android project, it’s ideal if very few users are on versions below 5.0. This makes it safe to drop support for Android 4.* and older.

At this point you can start estimating the work.

Estimate the standard tasks needed for project setup

Some tasks are standard for projects of any size, and don’t scale much up for larger app projects.

These standard tasks include:

Project creation and wiring up the stack of technologies you plan to start out with.
Initial app architecture setup, with the beginnings of a data model. The architecture and domain model will form while you build screens and features. But estimate time for some upfront planning at this point: it will pay off for the whole project.
Wiring up a few initial calls to the API you will use. Every endpoint, query and operation does not need to be complete up front, just set up a minimal network stack to verify that the backend responds to requests.
CI system setup (like Bitrise or Travis).
Analytics and crash reports setup (For instance Google Analytics and Crashlytics).

Estimate the main body of work: the screens

This is the part of the estimate that scales up based on the size of the project. The most obvious way to divide up the main work of the app is to look at the UI screens you need to build.

To be able to do any sort of estimates at this point, you will need at least rough wireframes of the screens. Hopefully you are able to ask questions of the designer as you do so: wireframes never tell the whole story.

For each screen, take into account the complexity drivers we mentioned above. Consider things like:

How dynamic is the screen? Static screens are simple. The more fields that can change and have varying visual states, the more work you have to account for.
How should the screen scale and change if the device has a smaller, or larger screen? If you need to support tablets, how different will it look there? Will it simply scale out in width (this rarely looks good without adjustments)? Or does the screen need a completely different layout for a large tablet?
Dynamic text content means you may have to consider edge cases: very short content, missing content, overflowing/long content, and so on.
Are there empty states you need to show until user performs work? Or loading states that show up while the API supplies data?
Will offline states require clever handling?
Does the screen involve a lot of microinteractions? Buttons that become visible once user can proceed? Progress indicators, transitions?
Will you need to do a lot of work on animations and screen transitions?

Go through each screen, come up with a rough number.

A simplified approach for very quick estimates

There may be a lot of screens and you may only have time for a very rough estimate. If so, categorize each screen as “simple”, “medium” and “complex”. Set an average estimate on each of those three types. Then add up the averages rather than doing a detailed estimate for each screen.

If possible, build a spike to refine your numbers

If you can, take a day or two to build a rough vertical spike for a couple of screens of varying complexity. The more you can learn from such experiments at this point, the more accurate all your numbers will be.

Estimate the standard tasks related to launch

Estimating and planning for launch tasks will help the project avoid surprises at the finish line. These tasks are small compared to the rest of the project, but it’s easy to forget to plan for them.

Final end to end integration testing, in a production environment or something very close to it. Even if you have tested each screen and feature in separation during development, you’ll need to spend time verifying everything before launch.
Setting up the Google Play store presence. Screenshots, marketing copy, banners, icons. I have seldom seen projects where everything is ready well before launch. Earmark time for collaborating on this.
Tracking crash reports after launch and fixing the major issues. You will not have an error free launch. Set aside time for handling the most common or serious issues that users run into.

Applying overheads

Take your current total estimated hours and add some percentage on top to account for testing and bugfixing.

Finally add a percentage on top of that to pad in some risk tolerance. All projects need some margins to handle unforeseen challenges during development.

Adding it all up

Congrats, you now have a theoretical total number of hours! But how many weeks or months will it actually take? You will need to translate the number of hours into calendar time.

Realistically: how many productive hours does each developer have per week? After meetings and other projects, what remains? This number is usually a good deal less than 40 hours per week.

Divide the total project hours by the realistic hours/week. You now have roughly how many weeks the project will take.

Run these numbers by any other developers who will work on the project. The other devs may have different opinions and valuable insights.

Present the numbers to the project stakeholders. Discuss them together. Make sure you all still agree on the constraints and assumptions made along the way.

What do you do with the estimate afterwards?

The project is greenlit, and you start working. Do you throw away all the work done above? No, you don’t.

If project goes ahead, keep your estimated numbers alive in a spreadsheet. Go through them each week. As the project progresses you will learn more about the problem space. You will see how much time things actually take, and you will be able to refine the numbers. This will decrease risk and provide valuable input for the project manager.

If you see that the initial estimates were overly optimistic (and they often are): have an honest, constructive conversation about that as early as possible.