There are basically two methods to estimate software development cost:
to) Guess how much will it cost.
b) Measure how much will it cost.
All estimation methods are derived from these two basic ways there.
The supporters of method the are always trying to hone their divination techniques and the supporters of the method b are always trying to improve their measurement techniques.
a) Estimation by measurement
It’s the oldest and most traditional way to estimate software.
One of the most popular techniques of this method is the score of points per function, which works more or less like this:
- The requirements are raised
- Use cases are designed based on the requirements
- The use cases in the functions that compose it are detailed (there is a range of previously established function types)
- Add the points of all functions (each type of function has a previously established number of points)
- Multiply the total of points by a unit of value (time, money...)
- A fat is applied.
There may be more factors influencing the project cost or price forecast (management cost, risk, aggregated value, etc.), but these other factors will be present depending on the nature and environment of the project and regardless of the estimation method chosen.
The value of each function point is a managerial decision that is based on previous experiences (own or market) and other marketing interests.
This is an incredibly effective method.
It is difficult to miss the estimate because the measurement is made on very detailed documents of everything that will be implemented. Each function is a very elementary software resource, like one of the letters of CRUD, whether the object is an entity or a relationship, etc. And it is easy to get the effort size right to make an implementation so small.
The problem is that telling everything that will be done requires you to know beforehand everything that will be done. That is, you have to do a good investment in understanding and detailing the scope even before starting to make software.
In projects of this type, this phase is natural take months and cost the work of various consultants, commercial and technical, who are usually the most experienced in the organization (the most expensive) because the premise is that this phase is completed with a lot of quality.
It is normal that this effort has other relevants in the project beyond the estimate, such as relying on comprehensive documentation produced at this stage to ensure that the right software will be developed, to rely on the documentation as a support for future maintenance, or to receive a subscription from the customer in this documentation (a contract) and armour counter-changes to ensure the margin or the deadline.
These other relevancies of the documentation bring a few more drawbacks to this method: you have to design the whole system before you learn all the necessary things about it, because learning, both from the client and from the team, happens during the implementation of the project and after the customer starts to see the software that is delivered.
If you hamper the changes, the customer may be missing opportunity to get more value from this project. And if you open yourself up to change, you’re throwing away the investment you made there in the beginning when you tried to predict everything that would be done and all the cost.
b) Guess by guess
This is the preferred process method Agile, since they value more the software running, earlier than comprehensive documentation; more collaborating with the client than the negotiation of contracts; they are open to change and even encourage it; believe that the best architecture and design emerge instead of being defined in advance; etc.
Since the idea here is just to allow change, it doesn’t make sense to invest a lot in closing a scope, so you usually build a macro view of the project and an approximate estimate, that can only be guessed since there is nothing to measure because it is not yet known exactly what will be done.
There are several methods of guessing. To define a general cost of the project before starting it, it is common to define the capacities or Features, that are the mega requirements of the project, guess how much it will cost each and add.
"Guess" is a correct term as it is admitted by the project that the future is uncertain, it is admitted that there is still no deep knowledge about each Feature or ability to be sure of all the work that will be necessary, and there is no intention to acquire this knowledge in advance - preference is given to start delivering software early and learn from it.
All estimates are based on previous experiences, and are difficult to achieve with precision because they are made on a macro and not detailed knowledge of the work that will be employed.
Still in theory you can deliver the capabilities provided within the budget because while parts of the software are made and presented to the customer, learning increases and allows you to stop performing work that previously seemed necessary.
The opposite can also happen and you identify that you made a very bad mistake in divination, and that it will be impossible to deliver the capabilities at the expected cost. In this case the new cost is assumed or the project is cancelled early before the damage is too great.
Note that in the other method you can also err badly - not the cost estimate but the forecast of what should be implemented because it predicted this without counting on the knowledge acquired during the project. In this case, when the project is cancelled, the entire cost of that initial phase is added to the loss. Or worse: since you already "knew" everything you needed to do and didn’t even want changes to come, you did not deliver the software in parts but left everything to the end - that is: risk of total loss.
Guesswork during the project
Well, so far I’ve only talked about the guesswork that happens at the beginning of the project. But and during the project, how the tasks are estimated (small requirements that will constitute the mega requirement - to such capacity/Feature)?
Here happens the same kind of divination based on empirical knowledge. Agile methods generally discourage estimation in hours, as they admit that one cannot predict with such a level of accuracy how much it will cost even a small requirement.
So it was invented story points which are an estimate of effort or size or complexity of the task, but are not directly related to cost in hours. The idea is that over time learn how many points can be made in a period and that this helps estimate the tasks that can be completed, according to their number of points, in a subsequent period of equal size.
In an effort to further untie the Agile estimates of the estimates in hours, we use Fibonacci scales or the sizes "P", "M" and "G" (type of t-shirt sizes) to discourage the association with hours (the immediate association becomes more difficult because the conversion calculation is more difficult or abstract).
To seek a more promising divination, there is still the Planning poker, that relies on the experience of several professionals at the same time to avoid deviations too large for more or for less. You can read how Planning poker works around or ask a specific question because only this gives a few paragraphs.
Down with the guesswork
Finally, the latest fad in the Agile universe is to look for alternatives so you don’t even have to guess estimates.
The reasoning is as follows: if measuring the project (here presented as "method a") does not serve the client well and if we are not so good at guessing ("method b"), how about forgetting this stop of estimating?
The name of this movement is #Noestimates And the idea, of course, is not just to stop estimating software, but to look for alternatives to it. Type "we can’t estimate, so what can we do instead to ensure the cost/value/term ratio for the customer?".
It is also considered that although the client needs to know how much he will spend and how long it will take, the estimate itself has no value for him, and what has no value, according to the Lean thought, should be eliminated from the process (OK, OK, this is another story, even longer, so another time).
Estimates for whom?
As I commented lightly, it is very questionable the value of estimates for the client.
Somehow he needs to know how much it’s gonna cost and when it’s done, okay. According to Agile methods, this can be solved with macro-capacity estimation/capabilities, interactive deliveries and open scope.
And how much will each task cost? How much will each of those 10 small requirements you plan to develop in the next two weeks cost? Do you really need to calculate this? Who will sell this measurement to? Who will pay for this effort? What is the value of nailing a Fibonacci number on each post in the picture?
So, if you are working alone or if your project allows, if there is no manager charging you, try to get rid of short-term estimates because your real value for the project so far has not been demonstrated.
Concluding remarks
As we talked about in the comments, the relationship between Fibonacci and Pomodoro does not exist.
Pomodoro is a technique to maintain focus.
And using Fibonacci sequence numbers in the estimates is precisely an effort to unlink cost estimates in hours.
A benchmark to give value to the answer
Ron Jeffries, one of the guys who signed the Agile Manifesto, who created Extreme Programing and who helped invent these "story points" and "team speed", is engaged in the movement #Noestimates. Even he has already apologized for having invented this business of estimating in points. Follows:
"There are a number of ideas on how to estimate using something other than time [hours]. Stitches, gummi bears, fibonacci numbers, t-shirt sizes. They were originally invented to obscure the aspect of time, so that management would not be tempted to misuse estimates. (I know: I was there when they were invented. Actually I must have invented the Points. If I invented it, I’m sorry now.)"
See this apology and many intererssantes things on: https://pragprog.com/magazines/2013-02/estimation-is-evil
super interesting the survey, but see : Estimate, is something inaccurate, for situations where unpredictable factors will occur, you raised points that reinforce this statement, ex:"something that we have never done before and we have no idea how long it takes"... I believe that the metrics derive from events that have already taken place... This is just one point that I have observed. Kanban, in my opinion, does not interfere directly in your questions, but something that could help would be https://pt.wikipedia.org/wiki/Ciclo_PDCA but let’s wait for other suggestions, I am very interested in the solution to the questions
– MagicHat
I have used APF (Function Point Analysis). It’s a little complex to understand because you have to get out of your head about the development itself, but we’ve been able to estimate with a minimal error rate. https://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o
– Marcelo Monteiro
the biggest problem of developing software is to estimate, alive on the skin this dilemma every day +1 by curiosity.
– Guilherme Lima
Leonardo, your questioning is very good. I am not "expert" on the subject, but I have a lot of interest. As you are starting out and don’t have a team yet this tends to be more complicated, but my tip is to estimate how much you would take to implement a simple form. Let’s say this form (tested, validated) equals 3 on its scale (let’s not think about hours now, right?), so for every new feature you have to estimate try to think like this "how many simple forms is that?". That’s what I apply, and by the way I learned from other people. In the future if you have u
– WLoh
Dude, where did you see this Pomodoro-associated newsreel with Fibonacci? If Fibonacci in estimate were an exact time multiplier, wouldn’t it be much easier to just point out the exact time in hours? Pomodoro, in turn, is a technique to maintain focus and has nothing to do with estimates. And Kanban, in turn, is a method for managing process changes, not a software development method, let alone working alone. Answer for you working alone: don’t waste too much energy making estimates - use this energy to make software.
– Caffé
@Caffé, I saw in a course on agile methodologies. But in fact it may be the way I wrote in the question that got weird. I did not assume a direct connection. What I saw was that Fibonacci is used to tell the possible values of time units. Already Pomodoro I saw that it is a technique to keep the focus, but it provides "units of time", measuring the time in pomodoros. But not that the two things are associated. What I understood is that you can apply the two things together, measuring the time in pomodoros and not in hours.
– SomeDeveloper
@Leonardo I understood. But it is not the case to apply them together no. They are very different things. The idea of using Fibonacci sequence is precisely not to link the estimate to an exact time, but to the complexity degree of the task/requirement, and without ignoring that something complex does not always take more than something simple. Roughly speaking, it is another, among many, "kick an estimate" technique. There seems to be a lot of interested people and the question has not been closed. I will try to give a useful answer. (Later).
– Caffé
Tip metaphorical for life: you will need a ruler and of a team. The ruler will be used to measure, of course. No matter which ruler you use or how you measure it (meters, yards, etc), always use the same ruler (otherwise your estimates will never be useful). The team will be used to build, of course, but also to define productivity. Certain teams will take longer, others less time, to produce 1 unit size of your ruler. Normal. Know this. How? Kick, miss, store and refine. Next time the estimate will be more accurate.
– Luiz Vieira
Hello Leonardo, I could post here, but I think it gets bad to read, when you have enough theory. One of the techniques used is Points per Function, give a searched is very simple and very close to expected. Basically you will find the functions of the software and analyze the amount of fields in the table, interfaces etc...
– Guilherme Guini