Speaking as a senior engineer myself, I disagree because time estimation in software is not a useful activity. The only thing it helps is political manipulation in a layer of management above you. Engineering work takes as long as it takes and often there are unknown blockers or surprise aspects of a problem that make it far more difficult than expected, so frequently that the initial estimate has no value to anyone, not even in a rough sense like, "will it take 2 hours or 30 hours." In my experience, a task estimated at 2 hours is equally as likely to take 30 hours as to actually take 2 hours, and there is no systematic way to know which case you're in.
Regular check-ins to catch the blocking issues early is much more important, and so teams should not waste time making estimates or tracking velocity. It's pure junk. Instead, start working and meet often to detect blocking issues as you go.
Regular check-ins to catch the blocking issues early is much more important, and so teams should not waste time making estimates or tracking velocity. It's pure junk. Instead, start working and meet often to detect blocking issues as you go.