In recent times has gained a new movement called #noestimates? What does that mean? What is the advantage of adopting this path? The movement, if we may call it, #noestimates is based on the statement that “estimates do not generate value”. Based on this, he preaches that we must avoid estimating, reducing such activity or even extinguishing it. He advocates that we should devise alternatives to estimation. Will be? Is this path for us? Let’s start by talking a bit about estimates. Estimates are by nature uncertain, i.e. they present the approximate value of something that we do not yet know, we do not master or we can not measure. Estimates are commonly used for forecasting. And why do we need to predict something? Simple: to be able to plan.
The idea with planning in a general way is to allow us to prepare for the future, especially with regard to making decisions that promote the effectiveness and efficiency of our project. In this article Planning a Sprint: Velocity and Estimation, eg, we talk about Sprint planning.
However, in addition, we should also understand that the process of estimating involves the search for knowledge about what one wants to estimate. In development projects, be it software or any other product or service, this means discussing the subject with the client / user. Search and investigate similar products or services or competitors. Often even promote discussions with experts. And this search for knowledge brings as a side effect a better understanding of what one wants to estimate. The more we know the more we agree, as we discussed in this post Well written Stories, more accurate estimations.
So, we come to the first important aspect, addressed in a way by #noestimates. We should only estimate if this is necessary for something that brings us value. Whether it is to forecast costs, deadlines, plan capacity, define project scope, understand dependencies between requirements and / or improve understanding about something we should do.
On the other hand, we know that estimates are inherently inaccurate, especially if wrong time. The literature related to software projects makes this very clear, as presented by Robert Glass, Here summarized:
- Most software estimates are made early in the life cycle when there is little understanding of the problem.
- Most of estimates is made by management or by marketing, not by who will actually build the software.
- Rarely estimates are redone.
Considering such observations, we can also deduce for which estimates should not be used.
- Determine something accurately.
- Set challenges.
- Reward performance.
- Cure lack of commitment.
- Establish confidence.
We know that estimates are often misused and need to be addressed. But estimates are an indispensable part of a planning process which, as we have seen above, serves at least to organize efforts towards the attainment of some objective.
How then? We tell the client that it is impossible to plan because we can not or should not estimate anything? Do we plan in detail all that we are going to do?
Well, we must first understand that the Agile movement perceived this problem in traditional development processes and established some policies that help reduce the negative side effects of estimates. I highlight the most related, in my view, the estimates: “Respond to changes rather than following a plan.” This means, for example, that in planning something we understand that our knowledge of what is planned will change and that we will need to review our planning. Everything to do with what we discussed above.
In general, the #noestimates movement, or the recommendations of it, follows the same path of many others that have arisen in agility: it brings several interesting insights, but it can not be applied in any way absolute or in any case.
Many projects and organizations with which we have contact already, in a way, when using Scrum, work with #noestimates. For the most part, teams estimate stories using story points. However, most do not estimate tasks by simply setting a timebox for them. It is common for teams to break their stories into tasks by limiting the size of their tasks so that they can be accomplished in a day, at most by two.
In conclusion, #noestimates is very valid, but does not mean that it should or can not be applied indiscriminately. If you add value, estimate is accurate. The most important thing to remember is that estimating by estimating only disrupts the team.
How has your experience in Scrum projects been? Does your team estimate it or not? Do you see value in estimating?
Olá,
Executamos um projeto de melhorias aqui na empresa e ao invés de estimarmos as tarefas seja por pontos, seja por unidades de tempo, definimos para cada uma um deadline de forma que não bloqueasse as tarefas seguintes e permitisse que entregássemos a Sprint com tudo que tinha sido planejado. Funcionou bem, porém, não tivemos capacidade de realizar uma mensuração mais precisa, como por exemplo, um burndown detalhado. O que conseguimos “reportar” era quantas tarefas definimos para a Sprint e quantas estavam em “To-Do”, “Doing” ou “Done”.
Oi Francilei,
Bem legal o approach de vocês. E a ideia quando se fala de tarefas é exatamente esta, ou seja, ao invés de estimar, fazer com que todas tenham um tamanho padrão a grosso modo, normalmente um ou dois dias. Com relação ao Burndown, normalmente o fazemos baseado nos pontos das histórias, não das tarefas. Mas também há formas de se fazer por tarefa. Só não entendi o que vocês chamam de deadline. Vocês estabelecem datas tarefa a tarefa, para cada história? Tudo durante a reunião de planning?