The estimation of the workload is an important part of the project and the reason why it is important may be different than normally thought. Generally speaking, an estimation of a single sprint often has only a little or no value. The reason for the estimation is not to commit to how many features the team can make in a sprint. We estimate things to predict the future from different angles. Some important estimation viewpoints are:

1. The productivity of the project

• If the workload estimation of the similar-sized properties increases during the project, it is usually a sign of problems. A common problem in this kind of situation is that technical debt has increased in the project and the building of the features is even more difficult.

2. The predictability in a short and long term

• Often a client needs to be able to estimate milestones in order to budget or apply for a loan to develop a product.

3. The prioritization of the backlog

• Once the customer understands how much the features cost, they can be prioritized from a business point of view to the appropriate point of the project timeline.

There are also projects where the time spent on workload estimation and the risks that may be bigger than the benefits of doing that. Examples of those are e.g. the products/projects of the Start-up companies whose requirements come primarily from end-user feedback. So it doesn’t make sense to estimate what will be done during next year. However, as a general rule, I recommend performing a workload estimation on all projects, as long as it is done lightly. Just remember that it is an estimation, not a promise.

Dangers of Software estimation in application development

This is one of my favorite subjects. The Scrum team selects a set of features that it commits to do in the next sprint. This can be harmful especially to the programmers who are not so experienced. If the team is afraid of a sprint failure, there are many creative ways for developers to get features done quickly. Usually, these creative ways lead to unintentional technical debt. That may backfire in the long or short term. Note that sometimes a deliberate technical debt is not a bad thing. Technical debt is a tool and it must be transparent. It needs to be taken consciously and the decision is made with the product owner of the customer.

If Scrum sprints never fail in your projects you should be concerned. Reasons for that may be; developers make creative solutions, take too few features into the sprint or give a too pessimistic estimation of the features. It is important that both, the developer team and the customer, understand that it is okay to fail in sprints. In fact, failure is a completely wrong word and should never be used! This can be successful only if there is trust between the customer and the developer team.

Last words

To summarize, the estimation of the workload is a critical part of the project. It is important especially at the beginning of the project. Too often an estimation is understood as a promise, which can lead to dangerous working habits. As practical advice, I would say that make a range for the estimation. When giving a range to the estimation of the workload it reflects how well the estimator knows the area. When estimation is given within a range the transparency of the project increases and highlights its uncertainties. If I tell you the project will take 1-2 months to reach the first milestone, it’s different than if it takes 1-5 months. In the latter case, the client may want to dig issues leading to such a wide range. The reason for these issues is often vague requirements or lack of those. Nice moments with estimations for everyone.