Estimating with limited information

Best client ever. You have gone through all the steps on the elicitation stage. You have worked on the epics broken them down properly and now have a healthy backlog of user stories that is representative of the app you will be building and now you can work on estimates. Awesome right?

Yes that would actually be awesome except in reality it just never happens. More often than not the client will want at least a ball park figure from the initial meeting when all you have is just a story.

The ideal way would be to reject this option and insist on a proper elicitation phase. Unfortunately that may not be practical. Fortunately there is a way of still getting to an estimate albeit a rough one.

Introducing function points.

Almost all business applications can be decomposed to the following major categories.


Includes the ways available to the user to feed data to the application. For web applications this would be forms, for mobile applications this would be dialog boxes, controls etc.

Depending on the application, exotic options maybe available such as finger tracking. They would still fall under this category


What the system displays back to the user.

Most common options would be:

  • Tables
  • Graphs
  • Messages
  • Reports

The only requirement is that the output be targeted at a human consumer.


Very similar to outputs with the distinctions that inquiries return results in raw format. This can be consumed by humans or machines.

The distinction is important because you rarely have to write a lot of code to get inquiries going.

Most common examples would include:

  • Database queries
  • Simple search
  • API GET to a simple resource

Logical Computations

Would include major manipulation to the data that is to be done by the system. Unless your system is purely CRUD, you will need this layer as the value add for your application.

Most common examples would include:

  • Run payroll for all employees
  • Calculate shortest distance between two points
  • Convert file types


In the connected world your app probably works with multiple other services to bring value to the user. You need to take this into account when doing your estimates. Examples of such would be:

  • Social login
  • Connection real time technlogies. eg Pusher, Firebase
  • Remote DBs eg Big Query
  • Remote file systems eg Dropbox, S3


Not all items in the categories would be equal in weight. As such you need to apply certain multipliers to the items to equalize them. Based on empirical analysis of software projects by Casper Jones in the book Applied Software Measurement: Global Analysis of Productivity and Quality. We have a reasonable basis for such weights.

Note in our nomenclature we classify Logical Internal Files as Logical Computations and Logical Interface Files as Integrations.


Suppose now you have come from the client meeting and you managed to pick up they would need an authentication system with Google+ and Twitter login. How would you go about that?

Starting with the categories highlighted above as a ticker list you would come up with something like this.

Epics are the major areas you we’re able to pick out. The categories are as discussed above. The complexity is a subjective opinion of the item to be built. For example in my case I consider complexity of login form in category Inputs to be low but consider a registration page in category Inputs to be high.

From this data we can now calculate the number of points based on Casper Jones multipliers.

What do the points mean?

The points have given you a size estimate but not a effort estimate. To get a effort estimate in developer hours you need to look back at previous projects to see how points map to time taken for individual teams or developers.

Let us assume that looking at previous data you note that the relation between developer hours and points for your team looks like this

    developer hours = points * 0.5

That is it takes a developer half an hour to complete a point.


    developer hours = 46 * 0.5 = 23

You can thus estimate that your developers will take 23 hours to complete the user authentication.

This estimation technique requires you to keep metrics on past projects but also enables you to very quickly compute estimates once you have a solid record of past performance.

The sheet used to do the computations can be found here.

Have you ever used point estimation on your own projects tell us in the comment section below.


Simple Software Estimation

Estimating how long it will take you to write software is a crucial yet often ignored skill. No matter the size of the project, it’s good to get into the habit of estimating your projects.

You don’t really need a complex system to achieve this. Here is a sample of a simple spreadsheet to get things of the ground.

Simple Estimation

Simple Estimation

This method was borrowed from Joel Spolsky book

Some important points to note concerning software estimation:


As usual we are back to our beloved principle, your estimation platform should be as simple as you can make it. That is tasks should be as fine grained as reasonably possible. You should be thinking in tasks lasting 30 mins to at most 2 hours. In short a coding session.

It’s possible that you have longer coding sessions but I still believe you should keep it to this chunks.

Let the developer do it

There is evidence that letting people set their own schedules leads to boosts in productivity. Below is the findings of research carried out by Lawrence and Jeffrey from the University of New Wales.

Programmer Productivity

Programmer Productivity

Of course there is a caveat to this general rule as can be seen above, system analysts generally give better estimates. This is because they have more estimating experience. Still unless you have the budget for a system analyst, stick to the rule.

This is a living file

The column Curr Estimate and Elapsed time should be continuously updated. It is my suggestion that you take 10 mins after your coding session to update this values.

When you start of, your estimates are likely to be spectacularly wrong, however, if you discipline yourself to always update the estimates you will slowly but surely get better at this task as you learn from your mistakes and hone your estimating skills.

Version your estimates

It is critical that your estimates are part of the source. Whenever you commit your code, ensure there is a csv with your estimates within your project.

This gives you an opportune time to actually update your estimates before a commit as well as help you track the time used over long periods.

Tracking time

On this item you can either decide to use a time tracking software such as Toggl or use general estimates based on time spent.

This really is a matter of personal choice though you should strongly consider time tracking software if you or your agency bill by the hour.

Other considerations

It is important that you include other items that affect the schedule but are not programming tasks, this would include:

  • vacation and family time
  • debugging time
  • buffer time
  • deployment time

I hope I have been able to show the importance of scheduling and a simple way of achieving it. If you agree or have an even better method, share with us on the comments below.