3 ms·
Again, this means you have a broken team and not a broken tool. In the situation you describe, there are three possibilities: either the new dev makes a reason
by matthewmacleod 7y ago
Again, this means you have a broken team and not a broken tool.
In the situation you describe, there are three possibilities: either the new dev makes a reasonable estimate and everybody else is wrong; the new dev is overestimating and more experienced devs are able to see that; or the new dev is not yet familiar with the point scale in use.
In the first case, great! We expose some hidden complexity in a system that might be taken for granted by the existing developers, and this helps refine an estimate for the new team structure. In the second and more likely case, we can respond by tightening up the scope and specification of a task to make it clear what is in and out of scope. And in the third, we can work to make sure the new team member gets a feel for the sizing system in use, which tends to take a little bit of time when changing team makeup.
These are not rituals and they are not unrealistic. They are specific tools aimed at solving real problems. It’s no surprise you have a bad experience if you are this aggressively dismissive of them.