Tag: software estimation

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:

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.

KISS

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.

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.