Detailed Project Estimation
Here we explain how we create a detailed estimation of our projects.
When we receive a new request for a software development project, we prepare a rough estimate to give the client an approximate figure of the project cost.
That is done before we sign an agreement with the client and start the actual work on the project.
When the ‘time and material’ contract is signed, we proceed with preparing a detailed estimate which is a more in-depth analysis of the expected project cost.
The detailed estimate includes the scope updates made during the rough estimate approval.
The scope of a detailed project estimate
Our detailed estimate of a mobile application development cost includes the following components:
- Application design
- IOS development
- Android development
- Quality assurance
- Project management
- Web application development
- Total project cost
Since mobile applications are usually developed for iOS and Android platforms simultaneously, we plan two development teams to take part in the project.
Thus, we invite developers of both platforms to participate in making the detailed project estimate.
The corresponding team leads also review the detailed estimation. We try to engage the same developers who calculate the detailed estimate in the actual project development. It ensures higher accuracy of the project estimate calculations and minimizes the risk of errors.
Please note that the detailed estimate does not include project planning – the preliminary work done before the first iteration of the project. Project planning usually takes about one week.
For more info about project planning, see this article.
How we estimate software development
The project scope consists of logical components or features to be implemented during its development.
In the process of preparing the detailed estimate, we calculate the time required to design and develop each of the project components.
The members of the team assigned to a particular project are selected in accordance with the technology and toolkit to be used for the project.
All project team participants are engaged full-time, which ensures the highest productivity and effectiveness of the product development flows and communication with the client.
How we estimate project management
Each project is delivered as a sequence of iterations, which are equal in length.
We consider 70-hour iterations the most effective. Out of each 70-hour period, about 20 hours are allocated to project management.
However, this figure may vary depending on the team size and structure.
Larger teams require more time for project management. At the same time, incredibly complex projects may also need more extensive project management, as they involve more communication within the team.
Besides, we add 35 hours of project management to the very last iteration of a project when PM involvement is especially intense. However, in team augmentation projects, the project management may be somewhat limited.
Effective communication is one of the factors of successful development.
We build our flows so that in each iteration a developer has approximately 15 hours of communication with other team members or the client.
Communication may be in the form of daily standups, team meetings or discussions of the demo at the end of an iteration or calls.
How we estimate QA
The quality assurance processes are expected to take about 20% of the total time allocated to the project development.
How we work with change requests
Please note that our detailed estimate includes only the project components, which have been positively approved for development.
Any features or functions still under discussion are left out of the scope of the detailed estimate and may be included later and have to be approved.
Any features or components added already during the project development and not included in the detailed estimate are very likely to increase the total development time and cost, eventually resulting in a later project delivery date.
For that reason, we place great emphasis on specifying all components of the project at the estimate stage.
Project estimation methodology
Often, the project scope is defined by analyzing the screenshots of the application pages and identifying the UI elements to be implemented.
However, this method sometimes fails to show the specific logic behind the UI and causes the estimate to omit some critical components.
Therefore, with the aim of achieving the highest accuracy possible, we are using the feature-based approach.
At the initial stage of project estimation, we isolate its major logical components, which we then break down into separate features. Within each element, we define particular tasks which serve as the basis for time and cost allocation for the estimation purposes.
For example, for an application, it is recommended to include the “Terms and Conditions” page, which the user should read and accept before proceeding to the application itself.
The functionality consists of a single feature – the user accesses the “Terms and Conditions.” To implement the feature, the team needs to perform the following tasks:
- Navigation from the “Settings” page
- Creation of the “Terms and Conditions” screen
- Creation of the “Terms and Conditions” content
- Adding the content to the screen
Preparation of a proper project estimate takes time, too. If we are planning a 600-hour project, we need about two working days (16 hours) to put together a detailed feature-based estimation.
Upside and downside estimates
To cover all possible scenarios and to provide for eventual inaccuracies, we usually prepare two estimates per project – upside, and downside.
The upside estimate describes the most optimistic project development scenario, while the downside estimate takes into account all issues and difficulties which may hinder the process.
The downside estimate also factors in the incomplete project specification with features or functions added after the project approval.
For example, if the project requires integrating a third-party functionality for which the API was not provided in time, this is likely to cause delays in the development flow.
The downside estimate covers such situations.
Naturally, we strive to deliver the project in accordance with the upside estimate.
At the same time, all project estimates are primarily focused on the development effort required to deliver the requested application, and the time consumption is secondary.
For that reason, we also calculate the downside estimation and advise the client to be prepared for this scenario, as well.
Now let’s look at the types of tasks we include in the detailed project estimate.
This is the central part of our detailed estimate because it specifies all project functionality components to be developed.
The task list also states the iterations required to complete each feature together with the number of hours to be allocated to it.
To show how the task list is built, we have used a detailed estimate of one of our projects. This list contains all types of tasks usually performed within the project scope.
1. Preliminary tasks
We schedule the initial functions at the beginning of the project timeline to prepare the development environment.
During this stage, the project team studies the available API documentation, if used, configures the development frameworks and tools, adds the necessary libraries.
During the preliminary phase, the project architects work on the architecture.
Before the development can start, the CI/CD tools and Crashlytics, the crash reporting platform, are configured and integrated.
2. Basic tasks
Regardless of the project purpose and scope, it always includes a set of basic tasks which are performed at its beginning – building methods for the API, database and cache for the project.
3. Push notifications
Most customer-facing applications use push notifications. They are implemented independently from the rest of the functionality; this is why we single them out into a separate task type.
For push notifications, our Android app uses Google Cloud Messaging (GCM). However, other messaging services can also be integrated.
Within the project scope, we distinguish large functionality components referred to as Epics in the Scrum terminology. The development of each feature is performed in several tasks.
The project estimate shows the number of hours required for the completion of each task. Any notes, comments or questions related to a particular task or feature, can be added to the “Comments” field.
Let’s look at the example of the “make a photo” functionality component. It consists of the following smaller features:
- A user can upload a photo from the camera gallery or make a photo with the device camera
- A user can view the uploaded photo
- A user can edit the photo
There may be several options for implementing the “edit the photo” feature – using the standard camera directly from the application or adding a unique style to the photo.
In the former case, the implementation can take approximately eight hours, while in the latter case the development time may be about 16 hours or even longer.
If a feature uses third-party libraries, this can also influence the time estimation. Integration of a ready-made library or developing a library from scratch takes different time.
Therefore, such features are to be estimated on a case-by-case basis.
Use of third-party components and similar requirements are to be noted in the comments to the feature because they affect the total project scope.
5. Finishing tasks
The finishing tasks are intended to complete the development and to deliver the application.
The final build needs to be reviewed and finalized with code protection and optimization tools appropriately configured (we use ProGuard for Android).
Within the scope of the finishing tasks, we also prepare the application content for uploading to the App Store and Google Play.
Advantages of our approach to making estimates
Using the detailed estimate, we have demonstrated the general principles of feature-based estimate preparation.
The benefits of such a plan to project estimates are as follows:
- Higher accuracy. Breaking the project down into features and then into smaller tasks makes the calculation of the required time and cost more accurate. Such an approach also ensures prompt response to any issues discovered during the project development.
- Better transparency. Connecting features to user stories, we create a better understanding of a particular feature purpose and goal. If, for example, the “login” component is expressed in such features as “a user can authorize,” “a user can add a picture,” and “a user can reset the password,” the overall idea of the function is much clearer. This approach allows avoiding excessive use of technical terminology that simplifies project estimate analysis for the customer.
- More efficient development. When the development flow is built on the basis of separate tasks laid down in the detailed estimate, the development team can save time on the thorough planning of the project design and architecture. The relations between the project components can also be seen from the project estimate.
Should you need any additional information on the project estimate principles adopted in Jasoren, please contact us.