“Prediction is very difficult, especially about the future”
– Niels Bohr

Software estimation is one of the most essential yet difficult parts of a project. Here are some ways to help you do it properly.

Estimation has always been a necessary activity in any software project. The purpose of it is to try to get a reasonable idea about what could be necessary in terms of money, time, and team size to succeed in the development. Since all those resources are always limited, a precise software estimation is a vital tool for creating the best plans.

We all know that estimation is one of the hardest parts of a software project. And no matter how much effort you put into an estimate, an estimate will always be an estimate. So, let’s review what we should be doing in order to do it correctly.

The art of great plans

Both estimation and planning are critical for a successful project, which is why we need plans in order to make better decisions and eliminate most of the risks we might find. We need to know when a project could be completed, how much time it would take, or how much money it would cost. Plans help us to understand if we are on track so that we deliver an expected functionality.

However, I have bad news (which I bet you already know): Doing a software estimation and planning appropriately are both very difficult and error prone, and most of the time, the final plans are wrong.

There is one other important factor to consider. Estimates given at the very beginning, when the product is still being defined and almost nothing is known, are obviously quite less accurate than those software estimations that could be given later when the requirements are already specified or, even better, when you have a detailed specification.

So, why do we need estimates and plans?

We know that estimating and planning are rather difficult. We also know that it is very likely that if we are estimating very early on, then we could be wrong. So, does it make sense to waste time on them?

The answer is YES!  You cannot plan without estimates in mind, and as we said before, plans help us to make decisions.

Given our estimates and plans, the company can, for example, coordinate marketing campaigns, schedule necessary training sessions with final users, and identify when hardware needs to be purchased/upgraded, just to name a few. So, even if we were inaccurate with our original estimate, the plan is still useful.

Software size estimation

If you are working with Agile, then you probably know that an Agile team usually has two kinds of estimates: estimates of size and estimates of duration. You first do an estimate of size, and then given that, you can estimate a duration.

When we talk about estimates of size, Story Points are probably the most used unit of measurement to estimate the effort (not complexity) that could be needed to implement a piece of work.

Read as well: 5 keys you can’t skip on your Agile process

The main thing about them is that the actual raw values are not important at all. What is really important are the relative values and the relationship among themselves. For example, if you estimate a User Story with 2 Story Points, it means that you think that the effort required to implement it is twice as much as a Story estimated with just 1 Story Point.

Therefore, when estimating a feature, all you need is to identify the size of it compared with all the other features already estimated. You still do not know exactly how long it will take, but you have identified if it is larger than FeatureA or similar to FeatureB.

What do you think the clients or stakeholders will ask you? ‘How complex is this feature?’ or ‘When will this project/feature be completed?’

Exactly, they do not care about the complexity of a User Story but how long it will take you to finish it. Story Points are not about the complexity of developing a feature but about the effort required.

When you are estimating the effort, you have to include, and consider as a whole, everything that could affect it, such as risk, uncertainty, amount of work, and even complexity.

However, always remember that a User Story that is more complex does not necessarily mean it needs to have more Story Points than a simpler one. If both of them will take you a similar effort to be implemented, then a similar amount of Story Points should be assigned to both.

Content related: 10 useful tips for software project estimation

To Estimate or to #NoEstimate. That’s the question

Software estimation is challenging for multiple reasons. Software is intangible, which makes it difficult to measure. The development is a creative process where each developer can have a very different productivity level, and requirements are, most of the time, vague. Even if requirements were pretty clear, it is complicated to know how long something will take as we would have never implemented exactly the same thing before.

Would you ask a scientist to estimate when the cure for a disease will be ready?

That is why during the last years, the #NoEstimates movement has gained new followers, which is just a quest for alternatives to the estimates driven software development. The intention is not to dismiss the estimates but to look for better arguments when making decisions. It is just an improvement.

Forecasting

We still need to know when something could be finished. If we are not going to estimate, how can we get that? Forecasting is the answer.

According to the Merriam Webster dictionary, estimate is “to judge tentatively or approximately the value or worth of” or “to determine roughly the size of”. On the other hand, forecasting is “calculating or predicting some future event usually as a result of analysis of available pertinent data”. You see the difference. Forecasting uses existing data while estimating does not.

The existing data that could be used, for example, are Lead Time, Cycle Time, or throughput. If your average throughput is 5 tasks per week and you have 20 tasks pending, then you can forecast that you could finish in around 4 weeks. You can do that thanks to the fact that all the tasks have a comparable size.

It is pretty similar to Story Points and velocity, but the difference is that instead of measuring an estimated value (Story Points), you are measuring real progress (throughput). Using this, you can stop guessing and start measuring actual progress.

To Sum Up

We have reviewed that software estimation and planning is not simple; however, estimating relative sizes of tasks using Story Points could make that process simpler.

In addition, there is a new wave that promotes the #NoEstimates movement as a solution.  This is not because estimates are difficult but because we can start to make decisions by using better information instead of our best guess.

No matter if you prefer one option or the other, the good news is that now you know how to do it right.

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.