Web development: how to avoid underestimating workload
Does your development team tend to underestimate their projected workloads? In this article, we’ll explore the ways to overcome this problem, and to improve the management of your web project by creating more accurate forecasts and schedules.
During the development of a web project using an agile methodology, under the Scrum method for example, it’s common for developers to underestimate the tasks during sprint planning meetings.
This article is going to outline some of the ways you can help prevent your development team from underestimating the features necessary to realize the project, and the time it will take to develop them.
The first point to mention is that underestimating a technical task while using an agile method is not really a problem in itself. At the end of each sprint – when the sprint backlog developments have all been delivered – you should be able to calculate the pace and velocity at which the development team is progressing through the project.
What is Velocity?
Velocity represents the number of effort points consumed at the end of a sprint. It’s an indicator used in the Scrum method to measure how much effort a developer team puts in to complete the tasks planned in a development cycle (known as a sprint).
The higher the velocity of the tech team, the faster the developers developing their products. For that reason, recording the velocities achieved by each team at the end of each sprint is highly recommended. The data allows project managers and team leaders to assign an average velocity to each team, which is highly valuable information when it comes to planning.
That being said, while velocity can be a good measure of a team’s pace and speed, using the value as the sole way to measure the performance of a team based is not recommended. There are a number of other aspects and values to consider when measuring or evaluating a development team’s performance.
In order to avoid situations where projections are under-estimated by an agile team, the team’s average velocity can be used as a benchmark for making sprint estimates.
If you already know the average velocity of the team that has been delegated the sprint tasks, then underestimation should not be an issue as the estimate will be based on historical data, rather than theoretical, subjective perceptions.
Forecasts on the web project will therefore be based on the actual velocity of the team – that is, based on what the team of developers is capable of producing. This will naturally vary from team to team.
When it comes to making performance comparisons between two teams, it’s important to remember that while two different teams may have different velocities, they also each have their own benchmarks.
One final point to add is that it’s best to also avoid asking a team of developers to try and improve the accuracy of their estimates by further inflating them. This will have no impact on the bottom line, as each team essentially has its own production capacity, and inflating estimates and projections will not have an effect on the actual work outcome.
Our development teams are regularly challenged by our Scrum Masters to help them progress and improve in their work. Discover our teams based in Madagascar, Mauritius and Vietnam.
