Who should participate in time estimation?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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

Answer 6

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.