Decorative photo of slightly golden sunlight shining through a confirous forest.
Unrelated photo by Lorenzo Hamers on Unsplash to make this post look nicer in social media shares.

When you ask your team for an estimate for a project, don’t give them an estimate to start from. If you do, you’ll likely cause anchoring bias. If you’re right, no harm done, but what if you’re not? I mean, the point of asking your team for an estimate is to get another, likely better informed opinion on how long the project is likely to take. If you accidentally bias their estimate you’re kind of defeating the purpose of asking them in the first place.

The context here is that I’ve been slowly reading Dr. Jorge Aranda’s Master’s Thesis Anchoring and Adjustment in Software Estimation while I’ve been on vacation because a) I kinda suck at estimation so the title looked very relevant to my interests and b) I have issues and it’s easier to for me to relax if I “earn” it by doing something useful.

Anyway, what Jorge Aranda’s experiment proved is that anchoring bias does affect software estimations. I haven’t finished reading it yet so the actual conclusion may differ from what I’m saying here, but I’m pretty confident about saying that if you want an accurate estimate you should avoid doing things that will obviously hit your team’s natural cognitive biases, like giving them an anchor. I’ve done that tons of times myself, I thought I was being helpful by giving my team my best guess and asking for a quick yes or no. It turns out that’s a bad idea, especially for large projects. For small tasks the harm you can cause is pretty limited, if you guess two days and the change actually takes three, meh. But for larger projects, if you guess three months and it actually takes four or five, now your boss is probably going to ask you a bunch of uncomfortable questions. Spare yourself and your team some stress by trying not to bias their estimates.

PS: Happy new year!