How to Estimate Mobile Projects 1. A Step by Step Guide
Read some advice on how to transform the project into achievable tasks and what to keep in mind during estimation.
This is the first part of articles series How to Estimate mobile projects. Read also Part 2 — Why Estimation Fails and How to Prevent This to learn about challenges and pitfalls that may occur.
If anyone asks two dev teams to estimate one project, most likely we will get two different estimates because each team’s judgement will be based on their experience and expertise.
In a perfect world, before engineers take off with an estimation,the project is already divided into functional modules, each is well-described, and interactions between them are documented, too. This project is evaluated by a team of experienced developers and they start development instantly. But the real world is not so rosy.
Start development from estimation
There is a widespread opinion that project estimations are a waste of time because they are very volatile in their nature: projects frequently turn out to be more challenging, new demands arrive, new features are added, members of the team come and go.
It is especially true in the case of a startup or an innovative project — where lots of things are to be validated or even completely pivoted. It’s hard to argue with harsh reality, but it’s always fun to look back at the end and realize how the project began and how naive we were.
Estimation of the project is the first step to a successful release.
The estimation is important: it explains how much time is needed to complete the project and get to release. It also helps to move from deliberation of the idea to the elaboration of the detailed plan; to estimate the complexity of system pieces; and to prioritize them.
Dig into the project’s problem domain
Here at Stanfy we estimate projects at different stages. The first stage is a rough estimation when the project only appears on the horizon. Here we explore the project’s industry (medicine, e-commerce, video streaming), and define users and what functions they may need.
We really need to understand the underlying domain and the problem we’re trying to solve.
At the rough estimation stage we devise how the user will work with the app and create the preliminary list of features. In order to make this list more accurate, we design low-fidelity wireframes, which show the user’s flow screen by screen inside the app. Wireframes allow us to put things in perspective: how the app’s features are correlated with the screens, and how the screens are connected to provide an intelligible user experience.
The next step is picking out the most tricky technological pieces: for example, whether the application has an offline mode with synchronization or a barcode scanner or live chat or video streaming. It allows us to understand what technological challenges may arise along the way, and what constraints we should keep in mind.
For example, integration with Spotlight Search is available only starting from iOS9; we should take this into account if we are going to create an app for iOS8, too. The more tricky features an application has, the more the roughly estimated time may differ from the actual one.
At this stage most customers think carefully about their lives, money and plans, and make a decision about whether they are ready to move forward or want to stop. After that comes Stage 2 of estimation, which we call ‘make it as accurate as you can’.
Design detailed screens
Having a detailed design is very important during the estimation phase. Steps to detailed screens are simple: low-fidelity wireframes, high-fidelity wireframe, interactive prototypes, designs. Lo-fi wireframes are created in the previous step, and they can be transformed into high-fidelity ones. Hi-fi wireframes show more details on the screen: layout, buttons, content placeholders. They pay respect to the design guidelines for every platform: hi-fi wireframes for iOS look different from those for Android.
Hi-fi wireframes can be easily transformed into interactive prototypes. One can open prototypes on mobile phones and interact with them like with real applications. Such prototypes are remarkably helpful for developers during the estimation phase; they help to understand an application’s navigation better and visualize its overall architecture.
Anyway, the result of estimating a project which has only wireframes — even interactive ones — is not completely accurate numbers.
The next stage is to transform wireframes into the set of designed screens. Looking at designs, developers understand the app even better: which components to use and whether it’s necessary to write custom elements or it’s enough to customise native ones.
A good design corresponds to guides: the Apple Human Interface Guidelines and the Android Design Guide. The sets of native components for the web, desktops and mobiles are each different, so if the designer uses complex or non-native components, it increases the resulting estimates. For example, the radio button is native for Web applications, but it has the analogues for mobile — a switch or toggle button. Nevertheless, estimating the prototypes is not as accurate as estimating already rendered designs.
Create a detailed feature list
It is hard to estimate the bare idea, so it’s necessary to create a features list or user stories that make up the project. Features are functional pieces that bring value to the user.
Describing features is something outside of the scope of the estimation and has to be done by the product owner’s team. Our development team clarifies and supplements the descriptions with the technical details.
For example, let’s consider a feature such as login via email. It consists of the login screen itself, keyboard behavior (it’s better to send data when the user presses the ‘done’ button on the keyboard than when he needs to hide the keyboard and look for the ‘send’ button behind it), data validation, sending requests to the server, handling responses, showing loading, showing error messages, etc.
Even the login feature that seemed so small hides many details, and a project is a set of such features. Usually we create a simple spreadsheet where features are divided into blocks, with less or more detailed descriptions of each.
Estimate effort
To estimate the feature means to find efforts (time and cost) that are required to get this feature done. There are different methods of estimation, but we use analogy based estimation, correlating the feature with its difficulty: easy, normal, hard, infinity — like game levels!
Let’s see examples.
- Easy: Login, forgot password, FAQ, help screens. Usually, static or dynamic screens, without too complex a design, often without sending requests to the server.
- Normal: Home screen, registration, tables, collections, custom controls. Usual screens with server requests, or custom controls.
- Hard: Third-party API integration, audio/video recording, streaming, chatting, custom gestures, synchronization, offline mode.
- Extreme. Usually they’re unclear and huge features. It’s better to divide them into smaller ones.
Sometimes it’s hard to define where the line is between groups. The rule is simple: round upward if you have doubts.
Let’s look at an example. Almost every mobile application uses tableview to show content: like showing tweets or cat photos. In the mobile world, the table is a list of the cells, which contain texts, pictures, dates and so on.
A table may look very simple, but from a developer’s perspective a simple table involves:
- Design cells (which can contain a lot of information and extra buttons and have flexible content depending on height).
- Loading data (send requests to the server, parse response, create data models)
- Loading more, pull-down-to-refresh.
- Showing loading, empty, and error states (like connection errors).
- Adding/removing items from the table. In my experience, removing items from the table can be very tricky — many apps crash due to data inconsistency.
- Merging content. Sometimes you will need to merge local content with data from the server.
- User interaction when tapping on the cell itself or on a button on the cell (usually the background changes to indicate the selected state and a new screen opens).
- Image caching for pictures in cells (if any).
- Nice animation when cells appear on the screen while scrolling (image fading or light bouncing, depending on the project style).
Looks complicated, right? And after all, a table should look nice and be scrolled smoothly.
But the good thing is that most of these features only need to be written once and can be reused with different tables inside one project or in different projects.
We are working on the list of components that are frequently used in many mobile applications, describing different user scenarios and corner cases. It’s useful to have this list on hand during project estimation to keep in mind unique peculiarities of every component.
The result of this stage is the list of the estimated features. The more hard or even ‘extreme’ features there are in the list, the more time the project takes.
Sort features by priority
Some features are more important than others. Therefore, we divide them into “must have”, “nice to have” and “cool, but later.” “Must-haves” are core features — without them the application won’t serve its purpose.
This technique is called the MoSCoW method; it allows you to focus on the most important requirements to provide users a valuable product as soon as possible.
Prioritizing has to be done by the product owner’s team right after creating the features list. Priorities help developers to focus on the most important features (without spending time on the deep study and evaluation of the features in the bottom of the icebox).
If we are talking about a chat application, for example, then the chatting itself is a core feature, but stickers’ support and sending audio messages can be added in the next release.
Often, a list of “cool but later” features is changed right after the first release when users give their feedback. It may turn out they really want a geolocation function to share with friends, and stickers can be postponed.
R&D features
Of course, there are features that we can’t estimate the value of at first. For such features, we do a little research, google and collect links to understand which way to go and what to expect. At the end of the estimation phase, we highlight such R&D features and consider that they may increase the overall estimated time.
For example, the integration with not very popular third-party services could be rather tricky. If a service is well documented, just to integrate it and be sure that it works correctly can make up around 20% of the overall work. But often, ‘correctly’ doesn’t mean ‘good enough’ — and you devote the remaining 80% of the time to customizing, improving or even hacking your app.
Do not estimate tech practices!
Some things we do not add to the features list even though we do them during development. Among these are engineering practices such as pair programming or writing tests on business logic or backend API. We also “automatically” integrate crash analytics tools (like Crashlytics) and use the continuous integration/continuous delivery services to regularly build and deliver the latest version of the app.
The time is required to set up such things, but usually this time is generously repaid even before the product is released. For example, first we must spend some time to obtain keys from the crash detecting system and configure your application to use them; but then analyzing the crash reports may save you an unbelievable amount of time in finding and fixing crashes before users notice them.
Solutions instead of the problems
During the estimation phase, understanding the challenges ahead is to some extent guesswork, as no problem is a real problem yet, and you have plenty of time to plan, simplify features, reiterate design and proceed on a clear path. If the proposed budget or schedule seems inadequate to do the work, we propose adjusting upward or downward the cost, schedule or features.
In essence, planning is about trying to understand the challenges ahead beforehand. In good teams, it is each member’s responsibility to maintain a special tone during estimations — talk about solutions to ‘possible problems’, not about ‘these monsters ahead’.
So,
the estimation process is a team job: the client describes his own vision, the product owner’s team clarifies the idea and creates and prioritizes the features list. Developers are immersed in the project area, trying to find out as much as possible about the project and the end-users. They estimate features, adding a technical point of view and trying not to forget anything.
Some features are typical for many applications, so they are easier to estimate (for example, you can like posts in almost every social app). It’s more complicated to estimate unique features that no one else has done before. Of course, much depends on the experience of the team and how many different unique applications they have developed.
Read more
Part 2 — Why Estimation Fails and How to Prevent This
P.S.
Found useful? Enjoyed my pony sketches? Feel free to like and share post! :)
Originally published on Stanfy’s blog on October 12, 2015.
