How to create an accurate estimate for your web project. Making evaluation more precise and fun.

In this short text, I’ll try to identify some reasons and give you a few tips on how to make estimates more accurate and fun.

Why are estimations often go wrong?

Web projects are not easy, predictable and repeatable things. Each project is different: there are different goals, different technologies to be used, and different purpose that project is meant to serve. If you want your web project to truly rock, you have to be creative, and use innovative, modern solutions. It means that you have to change and adapt to the always-changing environment, align with the market needs and users expectations.

There are never two exact same projects. Of course, some parts of the projects are repeatable, and good software house should be able to reuse some solutions to minimize work. But in order to make full use of those parts, there must be some work done so that they can be adapted to the creative vision of the new project. In the same time, you have to hurry to deliver your project as soon as possible so that you can keep ahead of your competitors with your brilliant idea, to get feedback from users as soon as possible or to simply start making money on your product.

So, as you can see, web projects are not a piece of cake, they are complex. They need a lot of non-routine work, which makes them unique. But that also affects the ease of estimation. There is one thing you have to remember: estimates are just that - estimates. You should never treat them differently, and you should never take them for granted.

So when evaluating a project, even though you are aware of a lot of common things that need to be considered, there is still a lot of room for creative work that is hard to estimate. And this is what makes your project so special. So what to do with this?

Don’t go for fixed-price quotations

The worst thing to do is to take your maybe still not fully complete idea to the software development company and ask for a detailed estimation. How would you expect them to do it precisely if even you don’t know everything yet?

Of course, if you insist, you’ll receive the quotation. But think about it - will it really be the best offer you can get? To make sure project is profitable, a software house will add some buffers for all the parts where your vision is not detailed enough or where it will be big of a risk for them. Even if you are ok with the offer, because you have enough budget, don’t expect your newly hired digital team to share your urge for excellence while developing your project. In the case of fixed-price valuation, every mistake made by software house, every “small change” you ask for, every time they’re exceeding their initial estimation, means their revenue will be lower. So don’t expect them to pursue perfection, because in their best interest is to create your project as quick as possible - this will be the most cost-effective option. There are also other reasons against fixed-price estimations - we wrote about it some time ago.

Ok, but how to deal with the estimation and valuing process then? What to do if your vision is still not 100% complete, but it’s ready enough to start making money on it? How to get most efficient estimation and how to ensure hired agency will share your expectations regarding the project you’re about to build together?

Start with MVP workshops

Firstly, you should focus on establishing the MVP (Minimum Viable Product). This minimum amount of work that is needed to start using a product is so much easier to estimate than the whole creative vision, which often is still blurry at some points.

People are quite good at estimating small chunks of work, but they really suck at estimating large ones. That’s because a lot of factors can influence the work if it takes more time. So try to figure it out step by step. A good software house should be able to offer you a workshop session.

At Merixstudio, we usually offer two-day workshop sessions to our clients. During such meetings, we carefully listen to the client’s idea. We try to divide it into small pieces of functionalities, and also we prioritize them together. The workshop is also the time when the client has a chance to meet the team that they’ll be working with. The output of the workshop session is a Product Backlog of the project which includes most clear elements at the top and those imprecise as well at the bottom. We also establish together the minimum amount of work that has to be done to release the project. After those preparations, we can provide the most likely budget range that you’ll need to develop your project.

Will it be fixed? No, it won’t, there are still blurry elements of the project, aren’t they? Besides, believe me, I’m sure you will come up with some changes that you would like to apply, which is totally understandable.

Do you have to pay for the workshop? Well, yes, you have to. That’s work that we have to do - it’s working time of our employees, whom we have to pay. But isn’t it better to invest a small part of your budget in establishing its direction and get a lot more accurate idea of the whole budget, than going for a whole project from the start and then fail at its end, when there is no money left?

If workshop shows that the project is not such a good idea or that it requires a lot more investment that you thought initially, you will only fail a small step, not an entire project that will cost you a lot of money. Maybe workshops will show that you should slightly change the course of your idea? Our experience shows that it’s quite common approach...

Workshops give you the possibility to review and adapt your idea so that your budget will be spent most effectively. For us, that means we have a complete understanding of your requirements and solid basis for some initial estimations. And how do we approach that?

Relative value is what matters

In our industry, the experience is the most important. For you, it means a higher chance of your project’s success. For us, it’s a guarantee that we know what we’re doing and how to deal with your project.

When it comes to estimation, we also rely highly on our previous experiences. Instead of trying to predict how much time something will take, we try to estimate an effort, complexity, and size of the work. By evaluating the size, we can later derive duration, because we know how much time we spent on similar size work last time. For instance, we’ve done a login/register forms a hundred times before, in a hundred possible ways: with custom API integration, with social media integration, with and without CAPTCHA, with and without auto-generated fields, with password strength meter and much more. So now, if you ask for an estimation of a login/registration form, we will establish the size of work and compare it with what we’ve done hundreds of times in different projects before. This way, we can derive duration based on our experience.

Ok, but what if you ask us to evaluate work that we’ve never done before? We use the same technique! We will try to compare the size of this project with other similar work from the past. Example: your task is pretty much twice more complicated as a different job we did in the past. We can assume it will take twice as long as before. To make it simple: estimate size - derive duration. Is it completely precise? No, of course, it is not. Remember what I wrote above: estimates are just estimates! But we can guarantee they are a lot more precise than estimating the whole project from the beginning.

Story points are relative units

To make it easier for the team to evaluate, we use relative values called story points. For example, instead of saying that login task will take 8h, we say that its size is for instance 2. What does it mean? Well, it means that it’s about twice as much work as a feature of size 1 and about half as much work as a feature of size 4. With this information, we can use those relative units to derive duration of certain functionalities, based on previous projects we worked on.

There are even more benefits of using story points. Because in Scrum (the framework that we use to manage the project) estimations are a team effort, using story points helps us to compensate for differences in team members’ skills. There is no doubt that a junior developer will work slower and longer on login form than a senior developer. But they can both agree on the size of the task.

Later, when we’re calculating duration based on size estimates, we will take into account a team members’ individual performance so that the valuation will best reflect the likely time.

Benefits of Agile estimating

In Scrum, there are a lot of different techniques of estimating by using story points or other relative units. All of them are designed to empower teamwork and to make estimation process as short as possible (we know you don’t want us to waste your time).

One of the most common is Planning Poker. It uses cards with Fibonacci code values as estimation numbers. Another well-known technique is a bucket system: the team groups all functionalities into buckets and compares them to other buckets and list them by size. After the all segments are created, they get digital numbers representing their size. This allows to valuating a lot of user stories quickly.

You don’t have to use correctly story points to determine feature’s size - any relative set of values would be great. At first, we began to use t-shirt sizes: XS, S, M, L, XL, XXL. This way our team was learning how to break their attachment to digits. They quickly get that, and we decided to switch to story points (mainly because of our project management tool, Jira, which supports story points).

Those techniques improve the accuracy of estimations as well as other things so important for the team. During evaluation sessions, team bonds strongly while working on the same assignment where each team member has the equal influence on the estimations. This makes it a great fun and team can get away a bit from a day-to-day routine.

In the same time, the team constantly has the same knowledge about the project, which decreases the number of misunderstandings that mean potential losses. During that time, we gained higher accuracy of our estimates, mostly because we consider different perspectives of all team members. It’s better for you as a client, because you can plan more precisely how to distribute your budget :)

Summary

I highlighted it two times before, and I will mention it one more time: when it comes to web projects, there is no such thing like exact and precise estimation. There is always something unpredictable, that will influence our assumptions.

While trying to estimate time of work, we often assume there is nothing that will be changing in the future, but come on, we all know that it’s not the truth. There are always some changes, adjustments that we come up with during the development process. And this is good! You should never give up looking for a perfect solution when it comes to creating your project. This is what makes your idea so special, and maybe this thing that you just came up with is the thing that will lead your project to success.

Merixstudio’s approach supports such changes, we encourage you to introduce them, but don’t expect us to be fixed with our estimations. If you can adapt your project, let us adapt our estimations. When using Scrum, we’re approaching work with small steps called sprints, which are time-boxed (usually 1-2 weeks of work). That means your risk is also minimized: during sprint review you’ll be able to decide if the direction we’re taking is what you’re expecting. The control is yours, all we need is a little bit of trust and a green light to do what we do best: take care of your project for you ;)