- Blog
#Data&AI #Development #Digital service design #Learning #Zure
EU AI Act timer is ticking, are you prepared?
- 17/09/2024
Reading time 9 minutes
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:
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.
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.
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.
Our newsletters contain stuff our crew is interested in: the articles we read, Azure news, Zure job opportunities, and so forth.
Please let us know what kind of content you are most interested about. Thank you!