In an IT project:

  1. Who should participate in time estimation? Developer, team leader, scrum master and etc?
  2. Whose vote should be counted most?
  • 2
    If you are doing Scrum: (a) there is no team leader. (b) the team should estimate collectively using Planning Poker. (c) and the guy that will likely do the task should be followed. A Scrum team is cross functional, and tasks are not assigned, but if the guy that master the DB say it should take 3 days. Probably it should take 3 days.
    – user2567
    Dec 9, 2010 at 8:01
  • 1
    You should be aware that an estimation is not a decision, but a (often difficult) prediction. There is no hierachy. There are no votes.
    – user281377
    Dec 9, 2010 at 10:20
  • @ammoQ The problem is that many project leader has that as decision! Dec 9, 2010 at 12:23
  • 2
    Yeah, that's a common mental misconception. Of course you can make the timeframe a decision, but then you have to estimate (i.e. predict) the archievable quality and completeness instead.
    – user281377
    Dec 9, 2010 at 12:43
  • @user281377 I like what you've got going: Heisenberg uncertainty principle for software development.
    – K.Steff
    Jul 30, 2012 at 1:47

6 Answers 6


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.)


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.


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".


A project has business requirements and deadlines coming from the top down. Those are "given estimations" for the first iteration.

These requirements must be partitioned to the biggest tasks having 100% known cost (like "enable logging" = 2 hours = "download log4j/SLF4J and plug in").

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.

  • 1
    "A project has business requirements + deadlines coming from the top down. Those are "given estimations" for the first iteration." - Sadly true and responsible for the sort of pressure that leads others to give inaccurate estimates as they try to stay within these deadlines despite what knowing how long it will really take. Dec 9, 2010 at 12:15
  • @Jon Hopkins - +1, fair point, but I described ideal process, in reality, as you said, technical managers sometimes prefer committing to apriori unrealistic schedule and finding "justifications" for delays as the project goes
    – bobah
    Dec 9, 2010 at 12:49
  • I'm not criticising your answer - just saying that this particular element is something to be wary of and that those estimating should if possible in the first instance not be told about these deadlines for fear that they be influenced by them. Dec 9, 2010 at 12:52
  • 1
    "A project has business requirements and deadlines coming from the top down." - Unless the people at the top are developers themselves with experience 'in the trenches', this is a recipe for DISASTER.
    – Vector
    Jul 29, 2012 at 22:48
  • Ever notice how MLB teams always have a former player as their manager in the dugout? That's because only a former player understands what it takes to get the job done and has the confidence of the guys taking the field.
    – Vector
    Jul 29, 2012 at 22:56

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



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.

  • 2
    Please improve this answer.
    – K.Steff
    Jul 30, 2012 at 1:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.