Time estimation and deadlines

Question

I started working in my current job as an Android developer right after graduation (1.5 months ago), my first task was to build a complaint application which includes the following features:

1. Registration using mobile number & SMS verification.
2. Sending complaints and storing complaint ticket for later use.
3. Tracking complaint status (querying the server for ticket status).
4. Service to for polling the server periodically and generating notification if the complaint's status has been changed.

I completed the task in around 3-4 weeks and was able to deliver the beta version of the app. I believe some of the code is "weak" mainly because of the pressure about deadlines, but nothing that causes serious performance issues.

Now, I'm asked to start on a new project and after being asked for an estimation (which I provided after reading articles about development time estimation) but I still don't have a good grasp on how to estimate the time needed for development, I'm now faced with unrealistic expectations & deadlines.

How can I give more accurate estimates when I'm given the requirements of an app (android specifically) so that I'm able to explain why such time is needed, and how can I deal with unrealistic deadlines & expectations set by the manager or the team leader?

Answer 1

The short answer is never give a fixed time estimate, always give a range. And then clearly document this in emails or the project plan (writing).

Long Answer: Fifty some off years of software development has proven fairly conclusively that estimating an entire project, before any work is done, has a success rate of around 20% or less (based on 80% of IT projects failing per industry surveys).

Unfortunately, it sounds like you're working for a company that still hasn't figured this reality out. When a company is unwilling to face reality, there is often nothing you can do. It's a matter of perception and trying to change perception is like trying to change the tides.

What I recommend is clearly documenting your current estimates and caveats. Make it clear your estimate is an estimate based on available data and without continuing the work, you can't get more detail. In traditional project management this is called "Order of Magnitude Estimating". Where at the start of the project an estimate was considered about 20% accurate. As you moved through the project the estimate would get more and more accurate. Think of it like a funnel that gets narrower the closer to release. So for a two year project, the initial release date is a range of a half year (2H 2018). Six months into the project the estimate moves to a quarter range (3Q 2018). A year into the project you get to a month (Oct 2018) and 18 months into the project you get to a week (3rd week of Oct, 2018).

You need to document what you know, what your estimate is based on and clearly state it is an estimate and try and assign some kind of variance to it. Part of this is to not give a fixed estimate, instead give a range estimate. You say "I think this could take between 4 and 8 weeks to complete. In two weeks, after coding starts, I can probably narrow that down to a week range."

This moves you into the concept of estimating in agile. You start with a lot of unknowns and you figure out what you can do based on what you have done.

Alternate- Date Fixed, Feature Flux Something that Scrum is greatly tailored to is setting a fixed date for release and keeping scope in flux. So instead of saying "I'll be done in 4 to 8 weeks", you say "I'll commit to shipping on March 17th. Right now I can commit to 4 of the twelve features on the list. In two weeks I'll be able to refine the scope and let you know the final scope I can commit to."

Answer 2

While Joel's answer is good, the reality we face in this business is we have to make commitments, we have to price our proposal with a price, not a range of possible prices.

Estimates should always be a range; however, you must also provide a target, something within that range. And then on top of this, the business may dictate another target...a target that represents price to win, which is very likely to be way lower than what you want as a target. In some cases, even outside your range.

The best way to help keep this target in a realistic range is with history. You need to capture your project results and store it so that you can reference what has happened in the past and build that into your thinking. Use industry information if you can get it. Second best is to include as many real experts...real...to help estimate the work. And finally, build a ton of contingency reserves over many of your projects so that you can fund those targets that were set too low.