Estimate a project or a task is a huge issue for all developers. Even if your experience allows you to be pretty sure that your estimations are complete and you shouldn’t exceed them then there always might occur some problems. The thing I struggle with is I always think as a developer. So, in the result, I give the expected time of development and a due date set with this estimation could be confusing or even wrong. Think about the Definition of Done – it’s a complex and long process between the moment when you get the information about the task and the date when it would be deployed on production environment. The development is only one of those steps and good estimations should cover the whole process and give you a space for coffee, xbox, wii and soccer table.

There are a couple techniques and methods to achieve this. Some of them are purposed to a different stage of the project or for preliminary estimations. I can be pretty sure that you know almost every of them and, most likely, used them to estimate some of your project as I did. But, it’s a good idea to have them written down in one place, just to remember.

Analogous Method

This is kind of my favourite of the very beginning of the project or before, when you get a specification, read and have no clue where to start, but you caught an idea, because you did quite similar project in the past. So, let’s compare example two projects from very high level point of view. Project 1 is the project I done, or you, and the Project 2 is our unknown future.

I can assume you that the specification of Project 2 seemed to be simple on the very beginning, but after a few months of work we realized that every single word matters and changes a lot. We had estimated this by two techniques. First, going through whole specification and writing down all necessary tasks, estimating them one at the time and counting all hours. Second, the Analogous Technique. The difference between results was just tremendous – about 300% (1000h vs 3000h), and the second was more accurate.

Moreover, time spent for working on estimations also differed. As you can see, there is no much things to compare in our table. You do not need to focus a lot on all aspects and risks of the project. Because you compare this to previous work with all problems, missing deadlines and features out of scope included, which cut the time necessary to devote.

As you can see I’ve written down only a couple of points to compare, but I recommend you to add there as much as possible. This will makes you able to see more differences and makes your estimations more accurate.

Expert Judgement

I call it as an estimation by recursion, because you have to ask an expert for help and he will try to estimate your project by one, picked method. One of methods to choose is, of course, the expert judgement.

It’s natural to ask somebody for help, so, do not hesitate to do this. Sometimes going to somebody works like an exercise with a rubber duck debugging. You explain your scope to the colleague and experience glare.

Three Point Estimate

This is one of my favourite. Programmers always have a problem with underestimated tasks, because of surely optimistic point of view. I must admit I’m an optimist too. During your planning sessions or even if you ask somebody there, you could meet a person who will tell – “I can do this in 8 hours”. But you thought that will take about 14 hours. Moreover, your Product Owner is indeed malcontent person and frequently changes his mind, so probably you will work about 20 hours. Your estimation is somewhere between these values, but where?

There are a few formulas which might be used to count the result value of your estimations. Most likely the result of all of them will be approximated, so I’d like to present only the one:

E = (o + 4m + p) / 6

Where the following signs mean:
– o – Optimistic estimation
– m – Most likely estimation
– p – Pessimistic estimation

To be more accurate in our Software Development’s estimations we can count a standard deviation of and add to the result:

SD = (o + p) / 6

The PERT says that to increase our confidence about the result we need to sum our estimations with multiplied standard deviation. When we add our E + SD the accuracy of result will be about 68%, but if we multiplied the SD by 1,6 we will reach 90% certainly

Example

Let’s just take a look at a simple example of little task of one work day:

Of course, you can deliver everything in estimated optimistic time, which I wish you, but it’s always good to have more time.

This method helps me to find a good balance between me as a hoper and the hard reality.

Planning Poker

This method is somehow an extension of three points estimation, or vice versa. Comes from Agile planning process. Get snacks, coffee, coca-cola, more snacks and sit down with your team at the poker table.

The cards have written estimation values: 1, 2, 3, 5, 8, 13, 21, 42, ?, BIG and coffee (from time to time you need to have a break). You can estimate in hours, but the finest way is to do this in story points. When you show your cards, there always will occur some differences between your estimations. You may choose the most likely, pessimistic and optimistic option and add this to three points estimation document.

This method is one of the finest, in my opinion. The biggest thing here is you need to explain every single task to know that everybody’s thinking about the same issue.

THE Deadline

As I mentioned in the beginning, all of these exercises are purposed for the development. The Definition Of Done says that there is a huge way to go between end of development and mark the task as a ready. You need to add time for QA, management, communication and documentation and it’s hard to remember about all of them. And certainly, it’s hard to remember that one day task (8h of development) might be ready after at least 3 days.

To help you with that I’ve prepared a little excel document where you can try to put your own estimations. I use this and seems to be working. Definitely, there are a lot more techniques and methods, but I wanted to present some picked by me, which I use. If you practise some others please do not hesitate to leave a comment.

Download Example Estimations Document