In an IT project:Who should participate in time estimation? Developer, team leader, scrum master and etc?Whose vote should be counted most?
Who should participate in time estimation?
project management;project;time management;time estimation
It's not so much about the people involved as the skills that need to be present:An good understanding of the problem domain - this is particularly important when the requirements are ambiguous or high level.  As a programmer who has never worked in travel to estimate work concerning ticket classes on a plane and they'll assume that there are 3 or 4 (economy, business, first etc.) but if you've worked in travel you'll know that there are dozens.  This may mean that a Business Analyst or expert user is involved, though over time developers themselves will build up this sort of knowledge.An understanding of the technology and the work that will be involved - usually a developer though a manager with recent experience who has the confidence of the team can often do the job.  Ideally though you get the person who will actually be doing the work as that way they're bought into the estimate.An understanding of the estimating process - this is key.  There needs to be an understanding of how to do a decent estimate, how to ensure it's right, check for appropriate levels of contingency, check for double counting or too much padding.  Usually a PM, development manager or senior developer will bring this, though in some processes a solid estimating template can provide the necessary guidance.Those skills can be in one person, though sometimes they'll need three or more, but the key thing is to make sure that those skills are present, not that particular people are present.That said, generally though I'd look for more than two people as you want the additional assurance that two or more people checking each others work brings.In terms of whose vote is counted most, it doesn't work like that.  It's a discussion and a negotiation.  If a manager thinks the developers estimate is too high he needs to explain why and challenge (not pressure) the developer to justify it and they need to reach a consensus.  In the event you can't reach that agreement I would say two things from experience:(a) Don't go with the number you want, it's just asking for trouble and what you want has no material impact on how quickly the work can be done.(b) In pretty much every case I've seen where a developer has been over ruled on an estimate, the final number has come out closer to what the developer thought than whoever was over ruling them - largely because they ignored point (a) above.(That said in agile I believe, and certainly in XP, the rule is that the developers control the estimates and that's final.  If the users want to lower the estimates they have to change the requirement for something simpler.)