Estimating is one of the most challenging tasks in software development. Most of the time our estimations are completely wrong. And it gets even worse the bigger the projects are.
However, we as a software development agency have to estimate projects, because clients request a price before they start a new project. We truly understand this, because they want to have at least some idea of how much a tool or solution will cost them. If later requirements will be added or changed, they understand that also the price will change. But to start, they at least want to have an overview of the costs.
Therefore, we developed and came up with our own strategy for estimating projects, that should reduce the risk of mixing up the estimation process with the final decision of the price for an offer. Plus, this strategy forces you to think about unexpected and unplanned things. Using this methodology, we were able to eliminate wrong estimations almost completely.
Step 1 - Identifying tasks
The very first step of our estimation process starts with identifying all necessary tasks and writing them down in a table. In addition, we internally also organize them into logical groups to give the individual tasks more context.
| Groups | Tasks |
|---|---|
| General | Basic Layout |
| General | Mobile Navigation |
| General | Desktop Navigation |
| Guest Area | Login |
| Guest Area | Registration |
| Guest Area | Send Email Confirmation Link |
| Guest Area | Forgot Password |
| Guest Area | Send Reset Password Link |
| ... | ... |
The above tasks are just an example. We try to identify every required task and write it down. If we think a task is harder to implement or could take very long, then we try to split it up into multiple tasks, so that we can estimate them better later on. As an example, you can see that sending the confirmation email of the registration is split up into a separate task from the registration itself.
Step 2 - Estimating tasks using the min/max strategy
In the second step, we estimate the defined tasks from the previous step using working hours, that we think are required for us to implement them. However, we don't estimate like most companies do by choosing a single value for every task. We rather choose two values, a minimum value and a maximum value.
The minimum value represents our least effort to implement the task. In this case everything goes well and nothing unplanned happens.
The maximum value represents our effort if maybe the task takes longer, because we didn't think about everything. Or we forgot about some things that must be also done.
In addition, we don't choose arbitrary values. We choose one of the following fixed defined values: 0, 2, 4, 8, 12, 16, 18, 24.
| Groups | Tasks | Min | Max |
|---|---|---|---|
| General | Basic Layout | 16 | 24 |
| General | Mobile Navigation | 4 | 8 |
| General | Desktop Navigation | 2 | 4 |
| Guest Area | Login | 8 | 12 |
| Guest Area | Registration | 4 | 8 |
| Guest Area | Send Email Confirmation Link | 2 | 4 |
| Guest Area | Forgot Password | 4 | 8 |
| Guest Area | Send Reset Password Link | 0 | 2 |
| ... | ... |
Choosing the minimum and maximum values for every task has the advantage that we avoid coming up during this estimation phase with the exact amount of work for every task. We found it also way easier and quicker to estimate both values than just one value, because we don't think too much about if we maybe forgot something or if we chose the right value. It's also easier to agree on the two values, if you estimate with two or more people.
By allowing to choose only from a fixed predefined set of possible hours, we reduce the headache of coming up with an exact value for the estimation. It's way easier to choose from one of the given values, rather than to come up with an exact value like for example 3 hours and 45 minutes.
In addition, the fixed defined list of hours forces you to think better about the real effort that is required to perform the task. We chose the values carefully upfront and with meaningful differences between them. It's not really a difference if you take 2 hours or 2 hours and 15 minutes to finish a task. But it's a difference, if it takes you 0 (meaning basically no effort), 2 or 4 hours.
Also, there are no values greater than 24 in the list of possible working hours to estimate. If you would want to estimate a task with more hours, it should be a sign that a task is not defined appropriately. In such a case, we try to break the task up into multiple subtasks and estimate them.
Step 3 - Sum estimation and choose price
In this last step, we sum up all the minimum and maximum estimated hours for all the tasks, so that we get two total values, the total minimum and total maximum hours. These two values now define the lower and upper boundaries for our estimation. Using our hourly rate we also calculate the minimum and maximum price.
Until this point, the entire estimation process focused solely on the effort and all technical aspects behind all the required work. No thoughts went into questions like the following:
- For which price should we offer this project?
- Do we have the time to do this project?
- Do we have any marketing effects when we realize this project?
- Could other projects follow after this project?
However, now is the time, where we ask ourselves these questions. The answers of these questions influence our decision, if we rather choose a price closer to the lower or upper boundaries. In addition, when it's rather a difficult project, then we tend to pick a price that is closer to the upper boundary. Otherwise, when it's rather a simple project, then we tend to pick a price that is closer to the lower boundary.
At the end, we finally have a price for the project with good estimation as a foundation.
Conclusion
Using this estimation strategy, we were able to optimize our offers and to come up with estimations closer and closer to the effective effort required later for the implementation.