Why do developers need estimates and a time-planning process?

CONTENT: To finish a project successfully, you first need to know how much time a certain task or project might take. Second, you need to make a time plan based on that estimate. Third, you need to use that time plan to inform your clients of when they can expect a product to be finished.

You could argue that, in the case of working at an agency, there’s no need for that bit of extra knowledge. An argument supporting that statement could be that it’s a project manager’s responsibility to create a viable time plan based on an estimate you provide. And in most cases that’s true. But let’s assume for the moment that, for whatever reason, you need to be able to answer the following question: When will a certain task be done?Now that you have the estimate, you have a calendar. Should be pretty straightforward, right? So why are there so many missed deadlines?Let’s walk through the following and see if we can put a stop to us missing deadlines in the future.It’s probably better to ask what inputs are we usually provided with when asked for an estimate? So here are three kinds of inputs, ordered according to their impact on an estimate’s precision.

Such a paper sheet might contain something like “Login via FB, Twitter, G+,” “API integration,” or “List of items with a tap-through details screen.” Basically, this is usually something created at our clients’ HQ as a result of brainstorming by a project’s various stakeholders. Also, this isn’t something we can use to make even a remotely accurate estimate as we have no UX, no UI, no animation specifications, etc. But we can use it to create a budget estimate for our client. (It’s also worth noting that this kind of an estimate will probably be off by 50 to 100% and that this error can go either way.)
This one can help us create an estimate with an error margin of about 20 to 40%. Things missing are UI and animations, which can prolong the time required for a certain feature.
This is most definitely something we can use to create the most accurate estimate. Based on our observations, the error margin has been in a 10% boundary so far.
This is another thing that comes to mind when an estimate is needed.

Who on your team has the greatest competence for such a task? Bear in mind that anyone can make an estimate. The question is just how accurate can that estimate be.Usually, a person with two or more years of experience working in a particular field is a pretty good candidate and for a very good reason. When working in a team, better yet in a company that nourishes high-quality coding standards, code reviews, and challenging your teammates’ decisions, that person is pretty much aware of most things that can go wrong during a feature development. That person is also aware of all the things that need to be done to produce the high-quality code we mentioned. So an estimate made by that person should, for each feature estimated, equal the total amount of work hours required to achieve that standard.Taking into account the inputs mentioned above, the preliminary (A4-sheet-powered) and UX estimates can be done by anyone matching the previously stated criteria. We suggest, however, that a post-UI (final) estimate be done by a developer who will be a lead on the project. Why is this so important? Because all of us take a slightly different amount of time for each feature. And though we can say that some features can take a bit more and some a bit less, this could lead to two estimates (one by a lead developer and the other by some senior developer unrelated to the project) that could differ up to 5%, which is not insignificant if we have a project that lasts for four to six months.

While working on the Ministry of Sound app, we had to implement, among other things, an audio player screen. When presented with a UX, which determines the basic layout for things, we gave a rough estimate of 2.5 days.