Hi, guys! As you know, we are doing our best for teaching Riter AI how to deal with main project management issues. We are convinced that these tasks should be automated as far as possible. Riter AI is learning to predict a sprint's success or failure, evaluate the accuracy of given assessments based on the previous experience, prevent possible threats associated with the human factor and much more. But in a lot of teams these tasks still remain the responsibility of users and most of them make the same mistakes which could be avoided.

One of the most frequent difficulties in software development is tasks estimation. We could find many reasons of this fact but, in our view, the main one is that everyone lies to each other. However paradoxical it may sound. Developers multiply the estimate, which seems to them real, by three. Managers then double it on top. And later their leadership will increase the estimates three times, as well as the stakeholders won't much hope to meet the deadlines.

There are a lot of attempts to formalize this process and to exclude the human factor, but by and large the task is still not solved and is being solved solely by the experience of managers who directly communicate with performers. The most efficient scheme uses conditional units of measure, also known as story points.

But even in this method there are its own drawbacks - here mutual lies are continued as well. The first thing that is told to a newcomer by old-timers is that their conditional chrono-parrot contains somewhere about five hours of development, and you should evaluate it that way - by dividing hour estimates by five. And that's where the lies begin. Everyone in his mind evaluates the task in hours, and then, using simple mathematical operations, turns it into story points. After that everybody attentively looks at the colleagues with a piercing gaze and thinks, whether the number of chrono-parrots turned out too small (or, conversely, large). And then it is changed to meet the expectations of colleagues and managers. This is repeated over and over again.

Instead, each team member should keep in a secret the information about the number of hours in a story point. Assert a taboo on the knowledge of other developers' ratio of converting hours to story points, and everything will immediately become fine. Each team participant perceives these parrots in his own way. When a developer thinks that the task can be done in five hours, he boldly says: "one parrot", not admitting to anyone how many time it will really take. One conditional parrot and that's all, no hours or deadlines. And everyone will understand it perfectly in their own way, because the coefficient is unique for each participant. Only then this mechanism will work. And now, unfortunately, the vast majority of teams know the rate of conversion hours into parrots, and therefore the trick does not work.

Riter development team