How to Create a Reverse Calendar to Build Applications

In the devCamp Freelancer Group I recently received the following question by Ryan Bent:

“I have question that I’m sure you’ll be able to help me with. I have client that wants a specific feature built and he wants an estimate of cost and his how long. I bill by the project and calculate my hours internally. So my question is, how do I estimate time to build a feature that I’ve never built before?”

This is such a common issue for developers that I wanted to dedicate a full guide to address the issue.

First and foremost I need to say that there is no magic wand that you can wave to generate an accurate proposal on a feature build that you’ve never created before. However, with that being said there are a number of steps you can take to put yourself in the best position to generate an estimate that is accurate as possible.

Reverse Development Calendar

Since I’m not a fan of high-level discussion, let’s jump right into how I would handle this type of situation. Thankfully I had to overcome this exact challenge just a few weeks ago.

The Challenge

A client presented me with a challenge I had never received before. They had a CRM system and they essentially needed the commission structure to be so flexible that it should be able to receive literally any type of input and generate a correct output. Does that sound a bit challenging? If you don’t think so you’re either you’re either incredibly brilliant or incredibly naive. Essentially the client was acting for a Turing complete machine for commission management. (If your computer science history is a bit rusty, this means that the application needs to be able to accept any type of input and ‘magically’ output the correct output).

When I heard the client request I responded with:

“Let me think through this for a few days”.

On a side note, it’s perfectly fine to tell a client that you need a little time to think through an issue. That’s not a sign of weakness or lack of skill. Saying this will let the client know that you’re methodical and like to think through challenging topics.

Now if you’re wondering why this feature was freaking me it, also note that the client was a SaaS company and that this feature had to work for thousands of their customers. This means that nothing could be hard coded into the code or database. One customer may be tracking widget commissions, another one might be tracking truck sales. So not only did the system have to be dynamic in terms of allowing for an infinite number of commission structure combinations, but the commission items could be describing an infinite number of items!

The Process

Immediately I realized that I wouldn’t be able to create an accurate project estimate off the top of my head. I had never built a system quite like this one and any estimate that I’d make would be a poor guess.

With that in mind, I decided to walk through a comprehensive estimation process. The process I followed is below:

Taking a deep dive into the user stories

I asked the client to send me a number of examples that I could use as case studies. For example, the CEO of the company could earn $1,000 a month or 10% of the entire company’s sales, depending on which value was higher. Another example is that a sale’s manager could earn a base salary, a percentage of the sales that their subordinates earned, and a recruiting bonus for any employees they hired. Additionally, the system had to accommodate arbitrary exceptions, for example, all of the regular employees might get $10 per sale, except for Bob, Bob gets $11…

These were three examples, the client ended up sending over 100 unique examples of commissions, simply based on the commissions based out last month! After about 10 minutes of going through the data, my fuzzy math estimated several million combinations of commissions that would have be accounted for. Obviously, this made the concept of hard coding the commission rules impossible.

Model it out

My next step was to create a set of UML models. Don’t worry if you’re not a UML pro, simply create a mind map with all of the parameters that you’ll need to take into account in order to account for all of the scenarios.

For example, for the commission feature I listed out each of the data elements to include in the calculations, along with additional criteria such as timeframes and triggers (triggers being benchmarks an employee could hit that would alter the commission percentage that she’d earn).

I utilized UML sequence diagrams to build out the flow for the user interface and the backend server algorithm.

Creating a Reverse Calendar

So… that was a long introduction, but we’re finally at the point where I build out a reverse calendar. The concept of reverse calendars is a pretty new idea for developers. However, I’ve discovered that they can be quite effective, especially for challenging tasks.;

What’s a reverse calendar? Great question! Normally when creating a timeline for a client you start at the beginning of the project timeline and create a list of items, such as:

• Scaffold the application
• Configure the database
• Integrate the outside libraries
• Etc

From that point, you can assign specific time estimates to each task and then add up all of the estimates to generate a comprehensive timeline.

Practical Implementation

With a reverse calendar, you turn the estimation process on its head. So instead of thinking from a linear perspective (start to end), you imagine the finished application (or feature). So in the case of the commission feature I created a visual prototype using Invision. In the prototype, I visually built the finished feature with all of the features that needed to be developed.

After I was happy with the visual prototype I started working backward. An example is that I imagined the final version of the system to have a drag and drop interface that allowed for admins to pull in any/all of the commission settings for each employee.

After building the prototype it became obvious that the system couldn’t have a traditional relational database since it would have to accommodate for a variable number of fields. With that in mind, I instantly realized that I would have to implement a NoSQL database into the application.

Example of Reverse Calendar

And I continued to work my way backward until I was at the beginning of the feature build. So my reverse calendar looked something like this:

• Implement drag and drop interface for generating settings.
• Build AJAX API calls between Rails and the View via jQuery to save settings.
• Configure JSON data store for managing variable key/value data set.
• Etc.

Creating the Estimate

By working my way backward I was able to think of tasks that I would never have thought about if I had taken the traditional linear approach. From this point, I started to list out my time estimate for each task. For the tasks that I had literally no clue on, I spent additional time attempting to break them down into more manageable steps. Each time I broke the tasks into smaller pieces they became easier to estimate. With that being said, for a few of the more complex tasks, I added a 20% time buffer over my initial estimate to ensure that I could hit the goal.

Summary

Like I said at the beginning of the guide, there is no magic solution to creating a perfect estimate, especially for features that you have little to no experience with. My estimates have improved with each new project I’ve taken on. However, if you follow this process you will discover that you will feel more confident with your estimates because the reverse calendar estimation approach starts with the end goal in mind, instead of the other way around.