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.

Inputs

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

Outputs

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.

Inquiries

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

Integrations

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

Multipliers

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.

Example

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.

Then

    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. https://docs.google.com/spreadsheets/d/1QEbdeK7TJ39a1efQOEuBu1J-_nP5KMUYTlYPNe7Hf2Y/edit?usp=sharing

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer