In an IT project:
- Who should participate in time estimation? Developer, team leader, scrum master and etc?
- Whose vote should be counted most?
It's not so much about the people involved as the skills that need to be present:
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.)
Who or whose should participate in time estimation? Developer, team leader, scrum master and etc?
I prefer all to be there in time estimation and we do the same here
Who or whose vote should be counted most?
Developer but still its all about team work again
I don't know if there's a one-size-fits-all answer to this question. Where I work, there are usually two engineers from the team that will be implementing the feature/fix that provide an estimate. So two engineers each provides a "min", "max" and "expected" estimate. We would usually expect both estimates to be reasonably consistent, so if they're wildly different, then further discussion may be required (perhaps one engineer had made assumptions that the other did not, etc).
In our situation, nobody's "vote" is counted as such. We typically just average the two estimates (remember, if they're not already in the same ballpark, then we reject both and start with the discussions over again, so taking the average is not a big leap). The estimates are only estimates, after all, so they don't need to be exact.
A project has business requirements and deadlines coming from the top down. Those are "given estimations" for the first iteration.
The estimation should be done at the highest possible level which already has enough technical expertise to do so.
The corrected estimations must travel back up in the form of "business visible feature" = "this amount of time" until they reach the business owner at an appropriate level, able to drop/change requirements or relax deadlines. Then back down. Until final convergence. In practice, people tend to ignore this phase or simplify it, which in turn may create risks associated with missed deadlines and opportunities.
In my experience, estimations tend to be done by the person who will most likely do the task itself. SCRUM teams should strive to be cross-functional, but after a while, certain types of tasks are usually done by the same people.
Of vital importance is to get an accept from the team on all estimates. If a developer feels they own an estimate, they will work to meet it. If the developers get handed an estimate that they did not do themselves and had no input or influence over, they will not feel the same level of responsibility to it and overdrafts will be explained away with "I told you it would take longer".
THE DEVELOPERS CHARGED WITH IMPLEMENTING THE PROJECT! NOBODY ELSE!
The developers doing the actual hands on work and the development team leaders are the only ones capable of properly estimating how much time it will really take. Only programmers familiar with the actual code base can understand the potential difficulties and pitfalls that may be encountered in the course of development. Everyone else is a 'spectator'.
In addition, the only way developers can be trusted to give accurate estimates is when business people trust them and rely on their expertise such that developers know they will not be penalized if their estimate doesn't meet business's expectations.
Rule of thumb: it will take at least 3 times as long as the estimate of any project manager or business person not intimately familiar with the challenges of hands on development and the code base in question.
As someone who has worked as a hands on developer both free-lance and as an employee in big corporations for nearly 20 years, I say this with utmost certaintly and the benefit of a great deal of bitter experience.