It may be a culture thing, but across the three companies I've worked at every estimate has been explicitly assuming a specific person handles it. Sometimes we've even given several estimates for the same task depending on who it gets assigned to. No one has ever found this odd. It's just obvious that different people have different skills and familiarity with different technologies or parts of the project.
There's no need to be offended either. I will gladly estimate a task taking longer for me to do when I'm not the original author or would be using languages and frameworks I don't have much experience in. We just give the estimates and let the PO prioritize what they want.
This is how planning should be done. Gauge people's expertise, put them on the path they can be most effective and then ask for their estimates. Take that to upper management and negotiate.
One problem with that is sometimes the estimates are done long before the work starts so when that item eventually gets to the top of the priority stack the person estimated for is working on something else instead. At this point things need to be re-estimated which can cause friction if the new estimate is longer (“but last time, you said…” or “when we asked Bob, he said…”).
What I've done in the past is give an estimate based on what a “standard” dev can be expected to do (everyone understands a junior is expected to be slower as they are new, that is why they are currently a junior and when they get up to speed they'll be promoted) with a comment on the ticket that the expected time will reduce by × if a named resource, or one of a group, is available to work on it. That way, medium term planning can be done on the basis of a “reasonable case” scenario and if the right people are available things will go better (and if there are multiple items in that state, short term planning will include deciding which ones being sped up, by using that person's time, confers most extra value).
Right, things are always probabilistic when it comes to us Humans :-)
I like to think of it like Algorithm Analysis; Best-Case (estimate by the expert mentioned above), Worst-Case (estimate by Noob who just joined the project) and Avg-Case (estimate by person who is already part of the project but is not responsible for that module). Add a fudge factor based on your reading of the circumstances and then haggle with Management. You now have a band with a upper bound and lower bound which can be realistic.
PS: You may find Douglas Hubbard's How to Measure Anything: Finding the Value of Intangibles in Business useful in this regard.
> But, but ... isn't every estimate supposed to be provisional?
Heh, no. It is an estimate when you are making it, but ten minutes later it magically becomes a commitment.
"Tasks like this usually take two days, sometimes one or three, very rarely more... so, two days on average."
"Okay, I am writing down: two days."
...two weeks later...
"How it is possible that the task took three days when it was estimated at two? You made the estimate! And you all were there at the planning, and no one said anything! As senior developers, you should make better estimates, this is unprofessional."
In an ideal world, yes, especially if requirements/scope/environments change. But the world is often not ideal. Often unless there is what they see as good reason (the definition of good may vary widely), managers & business planners don't like estimates going up in the short/medium term and pressure to try stick to the original estimate may happen.
That's exactly what I was thinking of when I said we sometimes give estimates depending on who it gets assigned to. "It'll take a day if X does it, but probably three if another SE does it".
