Feature Estimation: What is the real cost of adding a feature to a website?

January 2nd, 2021

Warning: This post is 3 years old. Some of this information may be out of date.

Lets imagine we are the agency supporting a legacy website and we've not worked on it for a while. The client calls and wants a new feature adding. Initial responses are that doesn't sound like a lot of work.

For example, lets say the client wants new delivery option adding to the checkout. The codebase is quite old and is without tests or documentation.

Your Project Manager asks for a time estimate to implement the feature. As it doesn't sound much you immediately reply with a “shouldn't take more than a few hours”.

To give even a reasonable estimate you should take the following into account:

• Are you familiar with the codebase?
• Is there a dev site already set up for you to work on?
• Is the codebase version controlled?
• Do you need to set up a development site?
• Is it simple to set up a development site for this code?
• Do you know enough about the moving parts to get it working?
• Can you get away with working on the live site???? (answer: never!)
• Do you understand what is involved in implementing the feature?
• Do you know what else adding the feature will affect?
• Can the client preview your feature easily enough?
• Have you accounted for client changes after feedback?
• Have you accounted for emails, telephone calls and discussions with the client and/or your Project Manager?
• Can you deploy your changes to live easily? DB Schema changes?
• Do you understand the requested work?
• Are you familiar with any third party services that may be needed?

If you have quantifiable answers for all the above you can then estimate the cost of the feature based on the following:

    Cost of feature  = ramp-up time (dev server, code familiarity etc) 
                       + initial feature implementation 
                       + testing 
                       + client demo 
                       + implementing client changes * 
                       + testing *
                       + client demo *
                       + client approval
                       + testing
                       + put live
                       + testing    
    
        * these steps can be repeated until client is happy.

In the above formula you:

• CAN'T know upfront the ramp up time unless you are familiar with the code and/or there are build scripts or setup instructions.
• CAN estimate the Initial Feature Implementation and testing.
• CAN estimate the Client Demo time.
• CAN'T really estimate the client feedback and implementation.
• CAN Add time for testing. If there are automated/scripted tests then this is easier to account, but if testing is a manual process, across multiple browsers/OS/devices then this estimate should be higher.
• CAN estimate the time to deploy the changes. (s)FTP, Git pull or CI can take care of the code changes, but DB schema changes may require taking the site offline.

An up-front discussion with the client and a written breakdown of what will be delivered will provide you with a good foothold to control feature creep.

Feature creep will always happen at the client demo stage as they have had the chance to see the work and naturally will find improvements or see something that wasn't thought about before.

Get to know your client

Estimating the project management aspects of the work can be done only if you are familiar with the client. Some will simply agree with most of the things you do and sign off pretty easily, others will tweak and add features in order to get what they need.

The 'Agile' Method

Most of the above is negated if the developer adopts an Agile Workflow. However, this isn't practical when working on inactive projects that are rarely touched. Agile is better for continuously developed projects.

I'd be interested in hearing peoples thoughts and experiences based on the above scenario. Please feel free to tweet me with your comments.