I’ve been in testing for 12 years, worked at Naumen and Yandex.Now managing a 150-person testing department at Contour and continuing to work as a tester on one of the teams.
After semi-annual performance reviews, managers from different teams told what goals they set for their testers. Every fifth one of them had the following: "To learn how to estimate the timeframe for testing tasks". Often such "deadline estimation" is desired not only from testers, but also from developers.
Timing estimates 95% of the time. Thank you, xkcd
I find the practice of the performer estimating deadlines for an individual task to be absolutely detrimental.
This is directly related to a lack of systems education and low requirements for managers.
Let me explain how this works.
About the works of the classics
Maxim Dorofeev – The Effect of Straightening of Terms
A person comes to us, sets a task, and asks how long it might take to complete it. In estimating the task, of course, we want to give a deadline by which we will definitely be done, and since a lot can happen (and we suspect that something will probably happen), we put a certain amount of time into the estimate.
Instead of immediately proceeding with the task, we "deal with the urgent" because "this task is not on fire yet"-we have the aforementioned reserve, after all.
The task starts "fuming, " and we get to it. If nothing happens, we are on time, but if something happens… We have already spent the reserve on this "something" and we are late as a result.
As a result, any deadline given as a deadline becomes a deadline before which the task will not be completed. This leads to particularly unpleasant consequences in teamwork, when a single task or project requires the cooperation of different specialists and different departments.
Man as rectifier (and diode) – illustration from Jedi Techniques. Video Also available.
Tom DeMarco — Thehuman factor
In part five of chapter one, there are references to studies on the dependence of performance on who did the timing estimation.
In short : the fact of the assessment itself affects the timing for the worse by about 40%.
I recommend reading. All of the factors listed in chapter five are relevant so far.
Deming and Niv — Experiment with red beads
Twice in the last year I heard from managers: "We learned how to meet deadlines on task estimates, now so-and-so programmer or tester does not violate the deadlines he called at all".
I think this is an extremely serious problem because this means that this programmer or tester is systematically and deliberately inflating deadlines, working at a relaxed pace, and lying to the manager. There are variations in the world, and non-infringing estimates of specific tasks means that such a person’s estimate is always to the right of the actual deadline distribution curve.
The authors mentioned in the title say that the only correct way to estimate deadlines is statistical. A package of typical tasks should be evaluated. "We all have different tasks"? That’s a lie. There won’t be very many different tasks at a span of a year. As a rule, such a statement is a sign of lack of reflection on the process and lack of exercise : decomposition, MVP, prototypes, standardization.
About customers who demand deadlines
First, it should be noted that more often than not – and this in itself is amusing – nothing depends on the answer of the executor, because the deadline already have The manager is not interested in how long we will be doing the task , and whether we will make it by the deadline and what exactly we will make it These are different questions and should be answered differently.
Typically, the answer to the question "will we meet the deadline" is analytics and MVP, quality development infrastructure, and the amount of technical debt, namely the complexity of refactoring and the availability of automatic regression tests.
Once again, a deadline estimate prevents a performer from meeting a deadline.
Second, there are a series of exercises in development. Not all of them are simple. They don’t directly answer the question "when will the feature be ready". However, they do reduce the size of delivery, reduce the complexity of development and testing, and ultimately reduce the variability of timelines.
- task decomposition
- restriction of unfinished work (the programmer does not take on new tasks until the old ones are out)
- separate releases of refactoring and subsequent features
- Separate release of backend, frontend and other parts of the product
- canary releases
- use ficha-flags
- testers’ ability to separate important defects from unimportant ones
- The team’s ability to release with unimportant defects
If the team does these exercises, and the manager is qualified, he does not need to require the performers to name a deadline to respond to the customers. If the exercises are not performed, then most likely any deadline the manager names will be a lie.
About incompetent managers
It’s very easy to confuse timing estimation (when the task will be done) and labor estimation (how much time it takes to develop the feature). Estimating deadlines, as we have already figured out, is if not harmful, then at least meaningless. But labor cost estimation is quite a useful exercise.
The need to estimate the labor cost when the task is done makes the useful exercises listed above : mainly the decomposition of this task.
But it must be remembered that The estimation of labor costs in a team with an incompetent manager very easily turns into an estimation of deadlines There’s a million cognitive distortions and a misunderstanding of how production chains work.
Case in point :
– How much time will you spend on this fic?
– A week and a half to write and three days to fix bugs.
– So in 3-4 weeks it will be ready?
So the difference between "I will spend a day on this task" and "the task will be ready in a day" is multiple and fundamental.
You teach life, but what have you accomplished yourself?
Yes, let’s talk about me and my team. Some of the listed exercises we do successfully, some we learn to do. Some we don’t, and that’s unfortunate.
I think we’ve learned to limit unfinished work, do pre-release refactoring, and separate important bugs from unimportant ones.
The way we estimate testing deadlines is this. We divide tasks into small, large and others. Small tasks are about half, they do duty tester in his spare time. Small tasks are marked in YouTrack with the tag "for an hour" and is done in one approach (from half an hour to two hours), if no complications.
The big tasks are tagged "project", and it’s immediately obvious that they just won’t happen. Each big task has a chip-lead whose job is to make sure that the exercises in the list above are done.
The rest of the exercises are not marked in any way. Exercises from the list start if the time to work on it exceeds an arbitrarily chosen and varied limit of 2 weeks.
If there’s an urgent task in the queue, you have to drop everything and do it. There is no need to evaluate it. However, it would be useful to specify a deadline to understand what defects and defects can be released. There are less than ten percent of such urgent tasks.
The last time I stayed late at work at the request of a manager to release an urgent task was over two years ago. Before that a couple of times, in 2015 and in 2016.
P.S. One of the most important skills in our job is not to do unnecessary bullshit. Including not engaging in "deadline estimation" and self-delusion. I wish you the same.
(Subscribe to our Telegram channel , it’s not bad there.)