In every company, employees are estimating work. In most cases, we are using expertise to answer a question about the time needed. The accountant just knows how long it takes him to fill a declaration for the tax authority. But in IT we are using various tools. We are doing it because development projects are complex and very rare fully predictable. Below you can find a couple of them which I had used.
General size – small, middle, big
It is a simple estimation, usually done by managers without many consultancies with the developers. The result of the estimation is often used to plan a roadmap for the next half year.
This is a variation of the General size approach, but with different names. For me, it is used by companies which would like to estimate in some methodology, but they can handle only T-Shirts.
Time team estimation
The most concrete method which answers (which is not accurate often) when the task will be finished. The answer could be done on different levels, with different precision. It could be done after a couple of meetings with the team, which is similar to General size estimation, but it also can be done after many workshops. Then estimation is much closer to the final execution time. Developers during those meetings split all functionality into small tasks and estimate them separately. The more graduality, the more accurate estimation will be, but also the more time is needed to give numbers.
The approach is used for small projects, and change requests. Also, it is used when the team is working on the contract agreement when all delay will be their cost.
Story points team estimation
Story points were metrics introduced by Agile. It estimates effort, not time. Story points have advantages and disadvantages. Every team has it own ‘price list’ of story points. In one team creating a button can cost 1 story point in another 13. The main issue with the story point is that this value doesn’t tell anything about the date of completion of the task. So, it results in the end in fallback to general size estimation done by a requester of the functionality.
In large projects done in fixed price schema, all the above ways of estimating are not an option. We cannot provide general information we also cannot make team estimation. If the whole project will take 10000 man-days it is not possible to analyze it in some rational time. In those cases, the estimator is used. This is usually an excel which transforms countable elements of software into time needed to create them. So, for example, integration with another system will cost 100 man-days and new window 20 man-days. These estimations are much inaccurate. The assumption is that in large projects everything will balance.
This is a current industry trend. Developers are assigned to the chosen business for a particular time. No one is doing other estimates than the general one. The business receives the time of development team and can ask them to do what they want. They set up the priority and the team is working on items from the top to the bottom. Business together with the team needs to decide what to do to deliver any functionality which makes sense.
Very often organizations are using different ways of estimating in the same way. For example, first, they do general estimating about the project, and the next no estimation approach is used. Everybody knows that in given time developers can make something valuable, but details are pushed down to the project manager and his ability to chose the right priorities.