I’ve been testing for 12 years, I worked at Naumen and Yandex. Now I lead the testing department of 150 people in the circuit and continue to work as a tester in one of the teams.

After a six-month performance review, managers from different teams told what goals they set for their testers. One out of five had this: "Learn to evaluate the timelines for testing tasks." Often such a “deadline assessment" is wanted not only from testers, but also from developers.

Estimation of terms in 95% of cases. Thank you xkcd .

I consider it absolutely harmful to practice when the contractor evaluates the deadlines for a separate task. This is directly related to the lack of system education and low requirements for managers.

Now I will explain how it works.

On the works of the classics

Maxim Dorofeev - The effect of straightening deadlines

I quote from the book " Jedi Techniques ", although one could quote Parkinson’s law :

A man comes to us, poses a task and asks how long it can take to complete it. Evaluating the task, we, of course, want to name the period by which we will be in time for sure, and since a lot can happen (and we suspect that something will happen for sure), we put a certain margin of time in the assessment.

Instead of immediately starting to perform the task, we are “dealing with the urgent”, since “this task is not yet burning” - we also have the aforementioned stock.

The task begins to “smoke”, and we proceed to it. If nothing happened, then we catch up on time, but if something happened ... We have already spent the reserve on this “something” and, as a result, are late.

As a result, any deadline named as a deadline becomes a deadline before which the task will not be completed. This leads to particularly unpleasant consequences during teamwork, when the cooperation of different specialists and different departments is required to complete one task or project.

Man as a rectifier (and diode) is an illustration from the Jedi Techniques. There is a video too.

Tom Demarco - The Human Factor

In the fifth part of the first chapter there are links to studies on the dependence of productivity on the one who performed the time evaluation.

In short: the fact of the assessment affects the terms for the worse by about 40%.

I recommend reading it. All the factors listed in the fifth chapter are still relevant.

Deming and Nive - An experiment with red beads

Over the past year, I heard twice from managers: "We have learned to meet deadlines for evaluating tasks, now such a programmer or tester does not violate the deadlines that I named."

I think this is an extremely serious problem, as this means that this programmer or tester systematically and deliberately overstates the deadlines, works on relaxation and lies to the manager . In the world there are variations and non-violation of estimates of specific tasks means that the assessment of such a person is always to the right of the distribution curve of the actual term of work.

The authors mentioned in the title say that the only true way to estimate the deadlines is through statistical methods. A package of typical tasks should be evaluated. “Do we have different tasks?” It's a lie. At the interval of a year there will be not so many different tasks. As a rule, such a statement is a sign of a lack of reflection on the process and failure to perform exercises: decomposition, MVP, prototypes, standardization.

About customers who require deadlines

Firstly, it should be noted that most often - and this in itself is funny - nothing depends on the response of the contractor, because there are already deadlines . The manager is interested not in how much time we will do the task , but whether we will be in time by the deadline and what we will be in time . These are different questions and they need to be answered in different ways.

As a rule, the answer to the question “will we be in time by the deadline” is analytics and MVP, a high-quality development infrastructure and the size of the technical debt, namely the difficulty of refactoring and the presence of automatic regression tests.

Once again: the timing estimate prevents the performer from catching up with the deadline.

Secondly, there is a series of exercises in development. Not all of them are simple. They do not directly provide an answer to the question "when the feature will be ready." However, they reduce the size of delivery, reduce the complexity of development and testing, and ultimately reduce the variability of terms.

• MVP
• task decomposition
• limitation of unfinished work (the programmer does not take new tasks until the old ones come out)
• separate releases of refactoring and subsequent features
• separate release of the backend, frontend and other parts of the product
• canary releases
• use of feature flags
• ability of testers to separate important defects from unimportant
• ability of a team to release with unimportant defects

If the team performs these exercises, and the manager is qualified, then to answer the customers he does not need to require the executors to specify a deadline. If the exercises are not performed, then most likely any term specified by the manager will be a lie.

About incompetent managers

It is very easy to confuse the estimate of terms (when the task will be done) and the estimate of labor costs (how long does it take to develop a feature). Estimation of terms, as we have already figured out, if not harmful, then at least pointless. But the assessment of labor costs is a rather useful exercise.

The need to evaluate the labor costs when the task is done makes us do the above useful exercises: mainly, the decomposition of this task.

But we must remember that the assessment of labor costs in a team with an incompetent manager very easily turns into an estimate of the terms . It involves a million cognitive distortions and a lack of understanding of how production chains work.

Life example:
- How much time will you spend on this feature?
- I’ll write a week and a half and fix bugs for three days.
- That is, in 3-4 weeks it will be ready?

That is, the difference between “I will spend the day on this task” and “the task will be ready in a day” is multiple and fundamental.

You teach life, and what did you achieve yourself?

Yes, let's talk about me and my team. We successfully do some of the listed exercises, some learn to do. Some are not, and this is sad.

I think that we have learned to limit unfinished work, do preliminary refactoring releases, and separate important bugs from unimportant ones.

Estimation of terms for testing we do so. We divide the tasks into small, large and others. About half of the small tasks, they are done by the tester on duty in his spare time. The small task is marked in YouTrack with the tag “for an hour” and is done in one approach (from half an hour to two hours), if there are no complications.

Large tasks are marked with the tag “project”, and it is immediately clear that it simply will not. Each large task has a feature lead, the task of which is to make sure that the exercises from the list above are done.

The remaining tasks are not marked in any way. Exercises from the list begin to be done if the time it takes to work on it exceeds an arbitrarily chosen and varied border of 2 weeks.

If an urgent task is in the queue, you need to drop everything and do it. No need to evaluate. However, it will be useful to clarify the deadline in order to understand what defects and defects can be released. There are less than ten percent of such urgent tasks.

The last time I was delayed at work at the request of a manager to release an urgent task, more than two years ago. Prior to this, a couple of times, in 2015 and in 2016.

PS One of the most important skills in our work is not to do unnecessary garbage. Including not to engage in "estimation of terms" and self-deception. Which I wish you too.

(Subscribe to our channel in Telegram , it's nice there.)