Productivity
No estimate
Most of project management frameworks are based on the idea of estimating the work to be done. This is a fundamental concept in project management, and it is used to plan the project, to track the progress, and to make decisions. However, there are some problems with estimating the work to be done.
Problems with estimation
- Estimates are often wrong: It is very difficult to estimate the work to be done accurately. There are many factors that can affect the estimate, such as the complexity of the work, the experience of the team, and the uncertainty of the project. As a result, estimates are often wrong, and the project can be delayed or over budget.
- Estimates are time-consuming: Estimating the work to be done takes time and effort. It requires the team to analyze the work, to break it down into tasks, and to estimate the time and effort required for each task. This can be a time-consuming process, and it can take time away from the actual work.
- Estimates can be misinterpreted: Estimates are often interpreted as a promise or a guarantee. The team is expected to meet the estimate, and if they don't, they can be blamed for not meeting the promise. This can create a lot of pressure on the team, and it can lead to poor decisions and poor quality work.
- Estimates can be misused: Since estimates are often interpreted as a promise or a guarantee, developers start to game the system. They pad their estimates to give themselves some buffer, or they underestimate the work to make themselves look good. And it breaks the whole purpose of estimating the work to be done.
No estimate movement
Given the problems with estimating the work to be done, some teams have started to adopt a no estimate approach. The idea is to stop estimating the work to be done, and to focus on delivering value instead.
Since it is still important to plan the project and track the progress, the no estimate approach uses other techniques to achieve these goals. For example, the team can break the work down into small tasks, and track the progress by counting the number of tasks completed. This gives the team a sense of progress, and it allows them to make decisions based on the actual work done, rather than on estimates. The progress can also be tracked using other metrics, such as the number of features delivered, the number of bugs fixed, or the number of customer requests handled or even better using business metrics.
From my experience, the most important result of estimating is the conversation that happens around it. While trying to estimate, you discuss with your teammates and you often solve the misunderstanding. The conversation is where the real value is, not the estimate itself. So, if you can have the conversation without the estimate, then you are already ahead of the game.
This movement is still relatively new, and it is not yet widely adopted in the dev community. It is still an ongoing debate, and there are many arguments for and against the no estimate approach. However, it is an interesting idea, and it is worth considering if you are struggling with estimating the work to be done.