---
title: Estimations
tags: [estimations]
---

# Estimations

The efforts we put into an estimation and the methodology we chose, highly depends on the following factors / context:

- The available level of detail for the scope
- The likelihood / chance of winning the project
- The available amount of time 👌

We use the following estimation methodologies (sorted by precision (low to high)):

- T-Shirt size estimation
- Timeline estimation
- Precise estimation (estimation sheet)

## T-Shirt size estimation

If we just want to give a real quick estimation it can be helpful to provide a T-Shirt size estimation that basically just has the following sizes:
**XS** - less than 20 MDs
**S** - 20-50 MDs
**M** - 50-100 MDs
**L** - 100-200 MDs
**X**L - 200-500 MDs

*MD: Man Days*

Based on experience with previous projects we try to find the right bucket (t-shirt size).

## Timeline (ballpark) estimation

Regardless if we are constrained by a deadline or not, we create a high level (waterfall) project plan to provide a high-level estimation. Similar to T-Shirt size estimation, this method is highly connected to our previous experiences / learnings.

**Example ballpark estimation:**

4 weeks of 1x UX/UI Designer

6 weeks of 1x Backend developer

8 weeks of 2x iOS/Android developers

2 weeks of full QA + 1 MD per week QA

3 MD / week Project Management / Solution architect

Considering overlaps etc. it could result into such a plan:


Resulting into a total ballpark estimation of: 150 MD + PM/SA efforts.

## Precise estimation

Precise estimations is the method when clients needs a more precise number and you have enough information to fill into our estimation sheet, such as

- List of epics / high-level features
- Code quality (code mode) needed for the project
- UX/UI awesomeness level
- Timeline

When we do precise estimations, we consider these common effort drivers:

- Amount of platforms involved (iOS, Android, Web, ...)
- Backend architecture (monolith vs microservices)
- Amount of third party integrations (especially non-standard ones)
- Business critical processes (payment, …) require more design + testing
- Handling of PII & GDPR requires more design + testing
- Can we use our beloved tech stack or do we have to navigate in foreign waters
- And of course we always consider deadlines! the higher the pressure, the higher the efforts!
- We estimate all features / epics (again based on experience with the platform or the kind of project).

We might add assumptions next to the estimates to allow for others to understand the numbers. The precision we use in the estimation sheet depends on the level of detail we know about the scope and also platform. It can range from 1 hr precision to 1 MD precision.

[Estimation sheet](https://docs.google.com/spreadsheets/d/1k_60YH0IVNtCQHS4DUFshzoecot0CfoR6tcxix6eXAg/edit#gid=0)

#### Estimation Sanity Checks
Especially if the projects is of bigger size (1000+ hours) it makes sense to double check the estimations by applying a second methodology. We do this by creating a timeline estimation independently of an already done estimation and comparing the outcome.

#### A note about solution architecture in projects
Based on the project complexity, we aim to plan for at least 5 MDs upfront for the Solution Architect. For a 4000 hours project this can be easily 20 MDs. Additionally the Solution Architect should be allocated ~10-20% of the time to a project (depending on project complexity and seniority of the remaining members).