As client approves the rough estimate, and all project details are clarified, we are ready to sign a contract and start a project planning stage, where – along with the project’s full scope of features, design and all related documentation – a detailed estimate will be made.
At BioCard, we estimate all of our products using both rough estimates and detailed estimates. The rough estimate gives a client an approximation of the project cost. We already wrote about how we do rough estimates. In this article we’ll look at how we make detailed estimates.
A detailed estimate accounts for services according to current rates:
To make a detailed estimate we engage at least two developers per platform. When the estimation is complete, the developers send it to their team lead for review. The same developers will also participate in the development process. This set of means allows us to achieve greater accuracy and avoid possible errors.
Estimation for design and development is calculated based on the amount of time per feature in the task list. It’s worth mentioning that all our designers and developers have only one project at a time. In our opinion, a fully involved team that is assembled with the consideration of all project’s technical needs is a keystone of success not only in our collaboration with a client, but of a product as well.
Estimation for project management is based on the following formula. If a project consists of 70-hour-long iterations, then the last iteration will allocate additional 35 hours for project management, since this is when managing tasks are the most extensive. All other iterations usually allocate around 20 hours for project and team management, in addition to other services, but this is not a fixed value because PM estimation depends on number of devs, designers and other team members. The more people we have, the more time PM needs. Complex projects require more PM time as well, since the more sophisticated the project is, the more communication it will require. In outstaff projects, on the other hand, this service is quite limited.
NOTE: Detailed estimate doesn’t include project planning stage – a preparation week before the first iteration.
The estimation for quality assurance is fixed at 20% of the overall time estimated for development.
It’s important to note, that success of project development largely depends on the effectiveness of communication in the team, so we pay a lot of attention to this aspect. A developer spends about 15 hours on communication per one iteration. This includes team meetings, daily chats, demos at the end of each iteration, retrospective meetings, and calls.
NOTE: We estimate only the functionality which will inevitably be included into sprints. If a certain feature still needs consideration, we will not include it into the detailed estimate. When this feature is confirmed, we’ll update the estimate.
Every new functionality not stipulated in the initial detailed estimate tends to increase the overall time the project will require, and, hence, shift the deadlines. Therefore, it’s important to think over all the details of the project early on.
There are several different approaches to estimations that a development agency may apply. Some time ago we estimated projects based on its screens. By looking at the elements on a page we could define what features needed to be implemented. However, this approach didn’t always allow us to achieve the maximum accuracy, since features in apps usually have some underlying logic which might go unnoticed.
That’s why we decided to give up the screen-oriented practice, and focused on features instead.
What does it mean to focus on features?
We currently split the whole project into chunks of functionality, which in turn get broken down into features relatively independent from one another. Then we break these features into even smaller technical tasks, each of which is estimated separately.
Obviously, the more time we spend on a detailed estimate, the more likely we are to “get it right.” For example, it’ll take about 16 hours on the average to do a feature-oriented estimate for a 600-hour-project.
What are low-case and high-case estimations?
Even though a feature-oriented estimate is the most effective solution (in our opinion), it’s still incredibly hard to estimate engineering projects with high accuracy. That’s why we provide two estimates – low-case and high-case – for both hours and cost.
A project can meet a low-case estimate only under the most favorable conditions. A high-case estimate is calculated taking into account possible issues that might occur in the process of development. Also, high-case estimate includes time needed to fix bugs, low-case assumes that we will not have bugs at all. Another issue that might appear is an incomplete list of requirements.
For example, say, we included a login functionality in the project’s scope but didn’t consider a given signature request which was one of the client’s requirements. This happened because we didn’t receive an API document, or this document wasn’t complete, or the feature was added after the iteration had already started.
A high-case estimate insures us against such scenarios.
We do our best to develop all features within the low-case estimate. But unfortunately, we cannot predict a 100% conformity, because an estimation is about rating efforts, not hours. That’s why the client must be ready to cover the worst-case estimation.
Now it’s time to discuss the meaty part of a detailed estimate!
The most important part of a detailed estimate is a task list. It represents features that will be built within a range of iterations with hours allocated for their implementation.
We made a sample of a detailed estimate of a popular Android dating app Tinder to give you an idea of what this document looks like. Let’s walk through the components of Tinder’s task list.
Before the actual development process starts, every project goes through a preparation stage, during which the developers research API documentation, setup project’s environment, and design its architecture. They also set up a project for Continuous Integration practice and adjust Crashlytics (Fabric), a crash reporting and build delivery system.
Every project includes some basic tasks that need to be completed at the very beginning of the development process. They include creating methods for API, DataBase, and Cache.
Almost all apps use push notifications, and Tinder is no exception. This feature doesn’t touch on other parts of the app’s functionality, so we considered it separately. Tinder most likely uses Google Cloud Messaging (GCM) service for Android to handle pushes, though it can be any other service as well.
Large chunks of functionality (we also call them Epics) are indicated in green. They are broken down into features which are indicated in blue. The latter are again broken down into smaller technical tasks. Each small task includes hours needed for its implementation. If there is something to clarify or suggest regarding a given feature, we put this in the “comments” column. Let’s take a closer look at that.
For example, a green function “make a photo” in the Tinder app is broken down into the following blue features:
The last feature can be implemented in several ways. One implementation would be to use a standard camera in the app, and takes about 8 hours on average to implement. However, if a photo needs to have a unique style and shape, the same feature may take twice as much time, or even more.
Another case may concern the use of third party libraries. In the Tinder app estimate there is a comment under the “edit picture” feature: “Here we can use a library, or create our own photo editor. This feature should be estimated separately.”
NOTE: If a given feature requires using a third party library or any other specific task, we note that in the comments since it makes an impact on the scope of the project.
In order to produce a fully-fledged release, our team of developers needs to finalize their work. Finalization includes review and preparation of the final build, setting up ProGuard to protect and optimize code (for Android), and uploading the final build to the app store. This also includes preparing an app’s content for Google Play.
Now you know all about our estimates for the Tinder app! Let’s summarize by listing advantages of detailed, feature-oriented estimates.
Advantages of feature-oriented estimates
A more thorough breakdown of every feature increases the accuracy of our estimates. What is more, a fully-fledged picture of the project allows us to foresee issues in the development process and address them early.
Smaller features associated with a given functionality represent user stories. For example, a login function is going to include “a user can authorize,” “a user can add a picture,” and “a user can reset a password.” This method of describing features avoids issues that stem from a misunderstanding of technical terms, and give the client a clear understanding of what will be implemented.
A detailed estimate serves as a basis for a project plan since it represents a clear technical task for a developer to use. This way the latter spends less time on designing a project’s architecture and building connections between chunks of functionality.