How to tell an estimation made by programmers is reasonable or not without technical skills?
I'm currently working on a game project. Since I don't have technical skills at all, sometimes it feels hard to doubt a programmer's estimation on a task is too much or not.
My solution is:
- Break down the stories to small tasks as possible so the time estimation becomes less vague.
- Look at the team to see if the estimation is overexaggerated or not.
Are there any better solutions for this? And also do you guys think there is a preferred way for programmers to communicate with PMs who don't know how to code?
emmalee last edited by
I see two parts to your question, and they have very different answers:
- How can I get the most accurate estimates?
There's a huge amount of information on this question, including techniques like smaller tasks (as you correctly proposed), relative estimates, team estimates, planning poker, and more.
- How can I trust the estimates I am given, since I don't have the technical expertise to make my own estimates?
Comparing past estimates to actuals is the standard empirical approach, whether using a metric like velocity or just plain old "Dev A's estimates on average were 30% too low" bookkeeping. This general approach is most reliable, but it also takes good bookkeeping and enough time to gather data.
A complementary approach would be for you to participate (primarily as a listener/observer) in team estimation discussions.
In general, an estimate produced by a team discussion is likely to be more reliable than an estimate produced by a single dev. This is partly because any tendencies to under/over-estimate by a single dev will be washed out when the team comes to consensus (this is related to your proposed solution of looking to see the reactions of other devs).
It's also because in order to produce a team estimate, there typically needs to be a team discussion of the work that will be involved, so things are less likely to be overlooked or forgotten. This is why I like planning poker, especially in the case where different people offer different estimates and then explain their reasoning, followed by discussion.
Even though you don't have technical skills, you can probably follow the discussion at a high level, enough to follow the logic and understand the types of work that are being discussed, and get a sense for the completeness of the discussion.