Why do developers need estimates and a time-planning process?
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.
What do we need to create a viable estimate?
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.
I. An A4-sized piece of paper listing bulleted-out project requirements
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.)
II. A complete UX of the app with the workflow included
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.
III. A complete UX/UI and a working prototype
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.
Who can create a viable estimate?
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.
Creating a simple project estimate
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.
The waveform-like spectrum analyzer animation has not been taken into consideration at this stage. The secondary estimate (a post-UI estimate) was put at 3.5 days.
Here’s a breakdown of the estimated tasks:
- Data integration (actual API integration not included) [4h] (4h due to screen layout, thus data being fetched being different for two different player configurations)
- Base layout and design implementation [3h] (Various screen sizes and styles for two different configurations)
- Offline and network connectivity issue detection [3h]
- Connecting controls to the underlying audio player [4h]
- Sharing [1h]
- Favoriting [1h] (This does not include service implementation for favoriting tracks and syncing with the backend)
- Chromecast integration [4h] (This does not include Chromecast player development, which actually took around 15 days)
- Image management: image download and blurred image caching [4h]
- Connecting various analytics libraries and custom events creation and management [4h]
28h total (3.5 days)
After talking with the client and our design team, they asked to include the spectrum analyzer animation. The animation was estimated to take about 24 hours (three days).
You can see the end result here.
So now we’ve talked about why we need an estimate, what we actually need to create the most exact estimate possible, and who should do the estimate. Next we will show how to create a time plan based on that estimate and how to determine which deadline we can commit to.
II. Time planning
Thanks to a team member of ours who pointed out the link and anonymous author who created the meme above, we’ve got this image that pretty correctly displays how things can easily go awry. Even the most correct estimates cannot be treated as deadlines. We need a time-planning process to determine deadlines; estimates and the time planning itself (in most cases) cannot be thought of as equivalents.
Again, why should we (the developers) know anything about time planning?
The answer is simple: because you should be able to say when a task will be done. If you’re working directly with a client without a project manager (PM) in the middle, you’ll need to tell the client when you expect a task to be finished. Now if you do have a PM, he or she can do the time planning. Still, it’s highly advisable to know that an estimate does not equal a delivery date. If you’re a project lead, you should be able to help your PM create the initial time plan.
Taking previous estimates into consideration, let’s try to answer the most frequent question we get from our clients and PMs: If we start our development Monday morning, when can we expect these tasks to be finished?
- Initial assumptions:
- Estimated time: 52h (6.5 days)
- Eight-hour workday (Let’s say we take an average of an 8hr workday into our calculation.)
- One developer on the project (Assuming it’s the developer who made the estimate, we can assign him or her a productivity factor of one.)
So what we did here basically was take the estimate and turn it into a deadline. And since this whole talk has been about explaining why that’s bad, this approach is obviously not going to work. The calculated delivery date is the next Tuesday at noon.
Why will this fail?
If you’re working at an agency, you usually work between eight to ten hours per day. But out of those hours, approximately only six hours are productive feature-wise. So by taking that fact alone into account, we’ve just lost 13 hours, which kind of leaves us having to explain to our client or PM why we won’t be able to deliver before end-of-day Wednesday. So we have effectively turned our 6.5-day task into a nine-day task.
How can we fix this?
So, again, let’s say we have an eight-hour workday. During that time, you will get interrupted (probably a lot). You’ll be asked to help on some task; you’ll be asked for advice; you’ll probably end up on some short sync; and, of course, you’ll be doing code reviews. Code reviews, even if only for 30 minutes per day, still take those 30 minutes from you and all the other developers who will need to fix their code as a result of your review.
- Initial assumptions:
- Estimated time: 52h (6.5 days)
- Six-hour [effectively] workday
- One developer on the project (Assuming it’s a junior with about six months of experience—0.4 efficiency)
So we’ve now corrected the initial calculation, taking into account six hours of productive output per day. But now we have another problem. The lead developer is not available for the task (he’s working on another project in parallel, called in sick, you name it), and a junior developer has to take over. By now you can probably guess the client won’t be getting what’s been promised on time. And though the fact that a junior developer is slower than a senior one may sound trivial, it’s crucial to be aware of each of your developer’s accuracy factors and/or the speed with which they deliver tasks.
How to predict an approximate delivery date?
When working with people, whether you’re a PM or a developer, you’re pretty much sure to pick up on their efficiency. Let’s say you have a lead and a junior developer on a project. A lead developer can typically be regarded as a person who can pull off a task without delay and so can be regarded as having an efficiency factor of one. A junior developer with six months of experience is usually somewhere between 0.4 and 0.5 efficiency tops (if the person is knowledgeable and learns quickly).
The reason the same feature takes one day for a senior and two days for a junior is not because the junior developer types more slowly. It’s because he or she is not accustomed to taking a complete picture into account and doesn’t have proper experience to know what to be aware of, etc. And that results in his or her code going through many more iterations than the senior developer’s code. Those iterations can relate to fixing reported bugs, fixing code to match coding standards/guidelines after code reviews, incorrect architectural approaches, etc.
Based on our data so far, the factors would be ranged something like this:
Given that info, we divide the estimated hours by the respective efficiency factor and see that our junior will need 130 hours. Translated into six-hour working days, that’s 22 workdays, i.e., more than a month.
How can we fix this?
The obvious answer here would be to not use a junior developer on such important tasks. Well, there are two things wrong with this. First, all of our tasks are important. Otherwise we would not be working on them. Second, juniors can’t sit idly in a glass jar until they’ve been deemed worthy and ready to produce high-quality code. They need to be given the opportunity to learn firsthand. So the solution here would be to put a senior and junior developer on the task in parallel.
- Estimated time: 52h (6.5 days)
- Deadline: Nine days from feature start
- Six-hour [effectively] workdays
- Two developers on project: a “six-month” junior and a senior (project development lead).
- A QA session at the end of the development
OK, let’s say we gave our junior 16 hours of tasks and the senior took it upon himself to complete the remaining 36 hours. That gives our junior seven days and our senior six days to complete their jobs. This means that by adding a junior to the project we’ve decreased our development time by two days only. That’s around 22%.
Usually we take some 25% of a feature’s development time as an estimate for that respective feature’s QA duration. That’s a bit less than two days, so we’re still inside our initial deadline.
The main difference between our estimate and time plan is their outcome: 6.5 days vs. nine days. That’s an approximately 40% time increase.
Remember, for estimates, make sure you have adequate assets to create the most accurate estimate possible. Also, have a project’s development lead create the estimate. For time planning, use efficient hours per day for your calculations, not official working hours. Also, bear in mind that different developers have different efficiency factors and include time spent on QA in the time plan.