Categories
Uncategorized

Why cut features and launch the product early or what is MVP?

Many of our customers come up to us asking if we could make an MVP for them. Yep. Even big corporate clients want what used to be a startup fad — and what is now an industry standard.

But what is an MVP? The abbreviation, standing for Minimal Viable Product, is used to imply you hit the market before you’re done with all the features. Why is it that popular then? Is it a fancy way of saying “whatever works is fine”, a bargain solution for low-budget projects… or a misused football term after all?

What is an MVP?

Speaking of minimal viable products, let’s get started with setting on the viability criteria. For a software piece, viability definition may lie within the range of “not crashing on launch” to “being able to compete against the leaders”. 

Within the Lean Production Methodology, where the MVP concept originated, V stands for “bringing value to the user”. That’s why they often read MVP as Minimal Valuable Product.

The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers

Frank Robinson, the author of the term

So, MVP is basically a killer feature, and the simplest buttons and handles one might need to make use of it. You cut all the bells and whistles off your concept, strip it of all the fancy design extras, and anything that is not crucial – as simple as that.

Why would you go for an MVP?

Here’s an example. Imagine you’re a fan of a particular sport — let’s say, boxing. And you want to become the new Muhammad Ali. So, you start training with all the passion and dedication and whatever else you may find in movies about Rocky Balboa. The question is: when will you take on your first fight?

Option one. You train for ages until you feel like you are two hundred percent fit and ready.

Option two. You get some pretty basic training and jump into the ring as soon the coach is sure you’ll make it to the last round without kicking the bucket. As soon as you are viable for the ring. 

Option one is tempting: if things go well, you’ll plow through the underdogs and face the big guys without losing your breath. Option two appears hurtful: if things go well, you will win. But should you win or should you lose, you won’t leave without a bruise.

However, there is a but. “If things go well” is the critical part in both scenarios. Once you enter the ring, reality comes at you fast. What if you figure out you missed something in your training? What if those in the ring are still trained better? What if the blows you receive hurt too much (shocker!)? Or – why not – what if what you deemed boxing and your passion was actually wrestling, so all your great punching skills are totally inapplicable? You’d better know that in three months than in ten years after you put your gloves on for the first time.

So, MVP is a reality check done the quickest and the cheapest way. It’s not actually cutting functions, but ensuring they are needed before you spend time and money on those.

REALITY CHECK AND REAL CHECKS

The MVP-centric approach grows popular as marketing skills become commonplace for entrepreneurs, no matter which is their sphere. TTM is the reason for that. TTM, or Time-to-market, is one of the key metrics for a new product. Time is always money, but when the market launch countdown is ticking, every minute costs you cash in many ways.

  • You want to pay for what others will pay for.

With all the research and insight behind it, the great idea your new product is based on is still a hypothesis until proven. It’s not like you already know the market craves your product, but you assume it is. There are no other means to make this hypothesis a fact but to check it on real customers. The earlier you hit the market, the quicker the feedback is on what would make your product more desirable.

  • Your product might be lucrative, but before it is in the market, it earns nothing.

With all the variety of monetization models available today, your product may be able to generate revenue long before it’s done and ready. Think of World of Tanks, the videogame that earned billions while being still in beta, or of all the mobile apps that are paying back the investments made. Ad-supported or subscription-based, bought in a one-time purchase or enhanced via microtransactions, your product might add some green lines to your bank account report as soon as it can deliver any value to your clients.

And yes, while the scope is small yet, you are safer in your experimenting with monetization models per se. No matter what, your missed revenue numbers will be the least frustrating.

Think of almost every successful software product. Yes, even the hardcore enterprise one would work. They never start as a one-size-fits-all solution, but as a demanded yet simple tool designed to perform a specific task.

  • Take a turn before you’ll have to brake for that 

Developing a complicated product before learning you have to adjust it to the market is not only about losing money on features discovered to be undemanded. The more had been done before a pivot, the more has to be done to perform one. You only have to remove seats and add panels to make a cargo van from a microbus, but should you try turning a Corvette into one, you’ll end up building it from scratch.

OK, are there any real-life MVP cases?

Telegram grew popular before it got the channels, stickers, secure calls, and bots. In the beginning, all it had was a boringly simple messenger with awesome encryption. It could do less than competitors, but it could keep your communication secure. MVP? Betcha.

SAP, the first ERP software coming into one’s mind, started from a pretty simple accounting system, which didn’t sport even 10% of what it has now. The term MVP was not even coined in by that time, but in fact, that was it – a basic solution, offering a new approach on quite a limited scope.

Zappos, the mid-2000 iconic apparel e-store began as a guy buying footwear on your demand from regular stores and sending it by mail. As simple as that. 

Moreover, an MVP may prove an idea before you spend zillions on can even become a business even before you expect them to do it!

Dota and Counter-Strike, as lucrative as they are now, began as community mods for popular games (Warcraft III and Half-Life, respectively). No ginormous teams of developers, designers, and community managers, no weekly content updates or events: they offered the very basic setup needed for a new gameplay pattern. A Minimally Playable Product.

HOW TO SCOPE AN MVP?

There is a mnemonic rule designed by Eric Rice, the author of the famous “The Lean Startup”: you take your first idea for an MVP, then cut that in half, and cut it in half again – and there you got what actually is an MVP.

For those hesitant on cutting, here’s another – not that brutal – rule of thumb we nurture here in Fora Soft.
You have to ask yourself three questions.

  • What is your favorite part of your big idea?
  • What do you need to use it?
  • If you had only 30% of your budget, what would you make first?

You may even put your imaginary budget threshold lower than that, until what fits it retains the uniqueness of your product and the very basic usability. Once you understand that you can’t push it down anymore, you got the MVP.

If it is still a complicated task like it may be, as you definitely love your idea, you can start with MVP-izing actual projects. Try to think about what makes Instagram, Google Docs, or your favorite game what they are. Take a shot on imagining they didn’t have all the features they boast now. Where is the border between “I’d go without this feature” and “Oh, it won’t be useless anymore”. 

QUICK. CHEAP. DIRTY?

Once you develop a vision of your product’s MVP, you start revving your engine. Time is money, so you want your Minimum Viable Precious right away.

Setting your step towards the MVP on your own is where you might run into a dilemma. On one hand, coding or testing in a rush never results in good code. On the other hand, the MVP stage is somewhat forgiving to the code quality — if it works, it works.

It’s up to you to find the balance between those, but the golden rule is: no matter how much duct tape is there under the hood, the user experience for the killer feature should be streamlined and lovely.  Whatever buggy and irrelevant to the key functions should be demolished mercilessly. Whatever is crucial and buggy should be a priority.

AND WHAT IF THEY COPY IT?

Well, everyone remembers the copycat cases – it happened to the MSQRD app, who’d had its minute in the limelight before every competitor got their own masks. Or Snapchat with its fading posts, which turned to be a fading fad (pun intended).  

That’s the concern faced by everyone taking (or sugging taking) the MVP path. If there is a killer feature, isn’t delivering a quick-and-basic product the simplest way to unwantedly hand it to bigger competitors, who’d wrap it up in glossy paper and grab your market in no time?

The short answer is yes. It is. If your killer feature is that great, all the big companies gonna copy it. Or release their own renditions already being in development. But the first one to release is the first one to win the audience — and is able either to retain it, entering the top league (like Zoom or Miro, the COVID-era superstars whose leadership is yet to be shattered). 

And even if the blue chips roll out their own, more refined solutions… Remember what happened to MSQRD? Facebook bought it. For a much bigger sum than they invested in development.

SO, WHY SHOULD I CUT FEATURES AND LAUNCH MY PRODUCT EARLY?

  • To check your idea and be able to refine it before there’s too much money spent;
  • To make the audience like your product before it is even totally complete;
  • To start earning before you’re done spending;
  • To make your product become a synonym to its killer feature. 

Can Fora Soft help you with an MVP?

Most certainly! On the MVP stage, it’s not just skill but experience that matters. A developer with a massive background in a certain area (media processing, streaming, and low-latency solutions in our case) is a shortcut to an MVP. Our developers, absolute pros cut the time-to-market, as they already know solutions for typical time-guzzling problems. Please, feel free to contact us via the Contact form, and we will get back to you right away!

Categories
Uncategorized

How to estimate the server cost for a video platform

Let’s take a look at how to estimate a video streaming platform after the launch.

The combined cost is based on the cost of traffic, data storing, and the server itself.

  • Traffic – the information that goes through our servers. In general, it’s audio and video streams. As a rule of thumb, services require way more money for the outgoing traffic than for the incoming traffic. So, we will only concentrate on the outgoing traffic here
  • Data storing – storing video conference recordings. You can store them on a rented server if there is not too much data. Otherwise, you will have to pay specifically for storing data
  • The server itself is the computer with the project. Usually, its rent costs a specific monthly amount. When one server isn’t enough because of too many users, people would use many servers instead. More on that later.
How_To_Estimate_Server_Cost_Video_Multimedia_Streaming

Traffic costs

Counting the traffic costs is the first task as it is one of the main expenditures on video streaming services. To complete it, one must calculate the amount of traffic that will go through our server within a chosen period of time. We will use 1 hour.

There is a convenient website to help us calculate the size of video files. How to use it? Insert the video resolution, duration, and FPS. You can compare terms such as 480p or 4k against “real” ones here.

You will see a sheet that might look difficult to understand, but it’s not true. Just search for Video File Size. This sheet has possible sizes that our video will have after using different compressing algorithms. For simplicity’s sake, we’ll use the compression YouTube uses. It is easy to realize and WebRTC video compression is close to the one we went with. The price will increase drastically if we decide to go with a lesser compression. Using more powerful compression may result in losing quality. It all depends on what our goal is. We will still be using YouTube-style compression as an example, and the amount of traffic we get in result will correspond to a one-way video stream.

For 1-on-1 chats, there will be 2 streams. If there are 1 streamer and 20 viewers – 20 streams. 2 streamers + 50 viewers – 100 streams (each of the 2 streams is sent to 50 viewers) or 102, if streamers receive streams from one another. Now, since we have the amount of traffic for a period of time, we need to multiply it by the price of our provider set. By the provider, we mean AWS, DigitalOcean, or our telecom provider if the servers are within our reach.

We only look at the outgoing traffic. That’s because the majority of providers offer either free unlimited incoming traffic or set such a low price that it’s not even worth checking here.

So, here is our traffic price. However, it’s just one third, so let’s move on to…

Price for storing data

If you don’t keep your stream recordings, feel free to skip this section, as the price that doesn’t concern storing video content is very low.

So, you need to keep video recordings on your server and you don’t know how much it will cost? Let us help you. Get the video size per one stream from the previous section and multiply it by the number of streamers. Multiply the result by the price for storing data on your server (calculate the price of HDD/SDD if that’s your private server).

So, all we have to do now is counting the price of keeping and supporting the server.

The server itself

Media server price

If the project is going to be somewhat loaded, you will have to pay for the hardware that sends out your streams. The amount of servers depends on the load, and they all have to be paid hourly. If you know the cost, perfect. If not, try adding something like $0,3 per hour (this is an average price for some Amazon EC2 category c5 servers)

Price for a reserved server

It’s more likely that your project will have at least one more central server with the main website on it. One would usually pay a fixed monthly amount for it. It’d be amazing if you knew how much your server cost. If you don’t, feel free to use the market average as of now – $30-$70 monthly. If it’s a simple landing without added functionality, $15 will probably do. However, if that’s a good website with an account room, video conference rooms list, text chat, notifications, and a stable online amount of more than 100 people daily, the server will cost more (from $50).

Examples

Take a 9-max meeting room. We’ll go with 640×480, compression algorithm equivalent to YouTube’s, 30 FPS (in the calculator this goes as 29.97), Amazon AWS c5 xlarge servers. Don’t forget to swap seconds for minutes!

Let’s calculate the traffic costs. Use the calculator and fill in the resolution and FPS. Check the result – 1 hour of a one-way video will take 639 Mb. Every user receives 8 streams from other participants. Therefore, we have 9*8=72 streams like that.

We get 46 GB per hour. Since we use Amazon, the traffic cost is $0,09-$0,01 per GB, depending on how much traffic was used up in the current month. In order to get to $0,01, we will have to use an immensely huge amount of traffic (40 TB), so we will use $0,08 for calculation. 46 GB by $0,08 is $3,68/h.

Let’s say we want to store the video; the size of 1 hour is 0,639 GB. We want to keep the video streams of all 9 people. The server will keep one video where other clips will be combined in one grid. Therefore, it will still take 0,639 GB. We use General Purpose SSD by Amazon S2. It costs $0,1 per GB, monthly! Therefore, we have to pay ~$0,06 for each hour of our videos each month they stay on our servers.

Amazon AWS c5 xlarge server costs $0,17 per hour. Add it to the traffic cost. Therefore, we get $3,85 as a cost for each hour of active meetings, and on top of that, $0,06 monthly for storing 1 hour of meetings.

If we want to imagine how much it will take us, we are going to need at least approximate numbers of streams daily and monthly.

Let’s say we have 4 hours of meetings like that in a day. Assuming there are 30 days in a month. we multiply 4 hours by $3,85 to get the service cost per day – $15,4, which we then multiply by 30 to find out the monthly cost with 4 hours of meetings daily =$462.

Let’s assume that we allow storing up to 100 hours of video. Add $6 monthly.

Amazon c5 large is our main server. It costs $45,99 when reserved.

To sum up all our approximate estimations for a month, we’ll pay $513,99.

Webinar with 2 streamers and 50 viewers

We keep the similar parameters: 640×480, compression algorithm equivalent to YouTube, 30 FPS, Amazon AWS c5 2xlarge servers.

The stream will still be 639 MB per hour. Since each streamer streams for 50 viewers, we have 100 streams – 63,9 GB per hour. The average cost of traffic stays at $0,08 per GB. 63,9 GB * $0,08 = $5,11 per hour.

We are not storing this video, but if we were, it would have been just 1 stream (we have 2 streamers, so we store them in the grid as 1 video), so it’s still 0,639 GB per hour. With the price of $0,01 for an hour, we’d get $0,05112 per month, for each hour of stored video.

The final result is $5,11 for an hour of a stream or $0,05112 per month for each hour of stored video, should we ever need that.

We’ll reserve Amazon c5 large as the main server. Its cost is still $45,99. So with the server, the cost is $1599,59.

1-on-1 video chats via p2p

We can tell from experience that one c5 large server can maintain more than 1000 simultaneous 1-on-1 video chats via p2p. We’ll be using that server. In this case, the traffic cost is minimal because we just help two users connect with each other. We don’t send any video streams through our servers. Nor does our traffic go through the server and we don’t need to calculate it. The price is negligible. We don’t store recordings, too.

The servers cost $0,17 per hour. For the insurance measures let’s imagine that we get a new server up each time we get 1000 people.

The approximate price for a month if we have up to 1000 chats every day, and they last for 8 hours. 0,17*8=$1,36 a day. Multiply that by 30 to get $40,8 a month.

The server we reserve is Amazon c5 large. With added $45,99, we have to pay $86,79 monthly.

Categories
Uncategorized

Mobile or web app if a budget is limited to one platform?

A mobile app or a web app? If you want to grow, attract new users, and retain old ones, you will have to do both. All major video service providers have mobile and web applications. Look no further than YouTube, Zoom, Instagram, TikTok, Skype

However, the development costs money, and the money isn’t always enough for all options. What to do, where to start? It’s difficult to answer these questions without any further information. It all comes down to what you want to do and what your plan of development is. In this article, we will explain some things about how to choose a platform and provide you with relevant statistics.

Let’s first take a look at the advantages of both options. Perhaps, it will already be enough for you to make a choice.

Advantages of a web app

  • Availability. A user doesn’t have to download an app from AppStore or Google Play. It’s enough to follow a link or simply google a website
  • Quick updates. The changes to a website go directly to a user
  • A big computer screen allows you to insert more information
  • You can choose a payment system. If you have a mobile app, you will have to pay Google Play or AppStore a 30% commission fee. On a website, you are free to choose any payment system you like, and the commission is ten times lower – 3-4%.
  • You can create a mobile website version. It will work on iOS and Android and cost much less than two native applications. We will compare mobile sites and apps later.

Advantages of a mobile app

  • Convenience. A cellphone is almost always with a user, and they can use an app any time they want.
  • Offline mode. Although a vast majority of apps need internet to work correctly, some developers allow an offline mode for the app. It’s impossible with a website.
  • Push notifications. You can launch a promotion, send an advertisement, or just remind inactive users about the app. SocialMediaToday’s research shows that push notifications are more effective than sending out emails or SMS.

An opportunity to create a mobile website version is a serious advantage when your budget is limited. By doing that, it’s possible to save money on iOS and Android apps. If, however, you think of doing that, you need to consider what you can get and what you can lose.

We get all the website advantages that we had before, plus a user can now use it anywhere where they have a phone and a cell service. It’s also worth noticing that the same development team will create a mobile version of a website. Mobile apps have some advantages, though:

  • Speed. They will launch and work faster. According to research conducted by Kissmetrics, 40% of users leave a website if it takes more than 3 seconds to load. It’s crucial because, according to the very same research, a loading delay in one second can lower conversion by 7%. What it means is that if your website makes $100k a day, you risk losing $2,5 mil a year.
  • Expanded functionality. You are free to use GPS, Bluetooth, camera, and all the platform functions in the app. It can also interact with other apps, integrate with social networks, etc.
  • Mobile apps are used more. Due to research by eMarketer, cellphone users spend 90% of their time on apps and only 10% of their time on websites.

With what do I start?

Although we’ve taken a look at the advantages of mobile apps and web apps, it’s still unclear as to what to go with first if the budget is limited. There’s no all-round solution, and it depends on your product type. Let’s create an algorithm using popular multimedia apps to help us with that.

Target audience

Are you creating an app for business people or just regular users? Your decision might differ based on your answer. As an example, let’s take YouTube and Zoom.

  • YouTube.is a service for regular people. According to official statistics, it’s being used by more than 2 billion people monthly, and 70% of them do that with a mobile app. It’s understandable. Whoever doesn’t watch YouTube nowadays? People go there on their way to work and home, on public transport, in queues, in traffic jams. The mobile app is a go-to thing for YouTube because access from anywhere is essential.
  • Zoom is a video conference service. It’s designed more for meetings and business calls; however, no one prohibits you from calling your mom on Zoom. But it’s the planned direction towards conferences that made Zoom to be used more on desktop computers. Judging by the official statistics, you can see that only about 10% of all registered users went into the meeting using their cellphone.

The conclusion is simple. If you expect your service to be used on a daily basis, and you want it to be accessible anywhere (Instagram, TikTok, WhatsApp), choose a mobile app. If you follow other goals, such as online conferences (Zoom, Google Meet), a web version is your pick. Your partner or employee won’t always be using the service. They will do it during a meeting.

Monetization opportunities 

Do you want to sell subscriptions or goods and services? When you sell digital content inside a mobile app, Google Play or AppStore will take a 30% commission fee. Unlike websites, where the payment will be not that significant, just 3-4%. It’s important because when you start out, you count every cent.

Also, according to Atrium research, people are ready to spend more on a website rather than on mobile apps. That means that if you sell expensive subscriptions, goods, or services, it’s more likely that a user will buy it on a website.

On the other hand, Jmango’s research shows that the conversion rate (a possibility that a user will buy something again later)  is higher on mobile apps.

Android vs. iOS

What to do if you need to create an app, and there is only enough budget for one of those? Let’s turn to the statistics.

According to DeviceAtlas’s research, there are more Android phones out there. But there are regions where that difference is not that substantial, and there are other regions where iOS devices prevail. The knowledge we can take from here is that our decision for a platform will be affected by the market at which the application is aimed. 

For example, in Argentina, Egypt, Brazil, India, and Indonesia iOS devices aren’t popular at all. In the States, Great Britain, Sweden, and Thailand iPhone competes hard with Android phones and sometimes even ends up on top.

BusinessOfApps also reports that those who own Apple devices pay two times more in apps that those with Android. Although there are fewer iOS devices, they are more expensive and are being used by more solvent people. 

DeviceAtlas statistics also show that iOS devices are popular in regions with a higher quality of life. You can see the region statistics for 2018 down below (blue is for iOS, green is for Android)

By the way, the same thing stays with mobile games industry – those with iOS pay more. Gamers from countries with a high quality of life (States, China, Japan), and 48% of the market is from America and China.

If you worry about your target audience age, don’t. Comscore reports that there is no difference in terms of age, so there is no point in diving deeper into this.

Taking everything into account, it’s safe to say that an iOS app is more attractive, and this operating system is better for a single app. iOS application will bring you more money. But it’s worth mentioning that although Apple earns more in general, things might change drastically in some countries. So, if you are looking at Europe, go with iOS. However, if the app is meant for use in a concrete country or city, gather more information, so you don’t have to kick yourself afterward.

Conclusion

A successful service should provide both mobile and web apps. Different platforms have different advantages and disadvantages and can attract different users. The choice is yours, and we can help you with it.

If you are not sure as to what platform to choose, feel free to contact us, and we will do our best to help you out!

Categories
Uncategorized

How to estimate time and effort for a software development project as a developer

Estimating IT projects is a pain. Whoever gave promises they couldn’t keep, only to work overtime just to meet the deadline they have set up for themselves?

When I started my path and tried to estimate my time spent while being a developer, I always underestimated things. Every time there would appear a job I didn’t account for. Colleagues told me to multiply my estimates by 2, 3, the number Pi. Only it didn’t help to increase the estimation accuracy, just added other problems. For example, when I had to explain where the high numbers came from.

15 years have passed since then. Over this time, I’ve estimated over 250 projects, got a lot of experience, and now I’m willing to share my thoughts on the topic.

Hopefully, this article will improve the quality of the estimations you’re giving.

Why estimate?

No more than 29% of projects end up in success, according to the research by The Standish Group, conducted in 2015. The other 71% either failed or exceeded the triple limitation system: deadline, functionality, budget.

From these statistics, we can assume that project estimation is often not what it should be. Does it mean that this process is pointless? There’s even a movement on the Internet that invites you to not estimate anything and just write a code, so that whatever happens – happens (search by #noestimates).

Not having any estimations does sound appealing, but let me give you an example. Imagine that you come to a restaurant and order a steak and a bottle of wine but there are no prices on the menu. You ask a waiter: “how much?”, and he goes, “depends on how long it takes the chef to cook. Order, please. You’ll get your food, you’ll eat it and then we’ll tell you how much it cost”.

There can also be an Agile-like option: “The chef will cook your meal, and you’ll be paying as he proceeds. Do this, please, unless you’re out of money. When you have no more money, the chef will stop cooking. The steak won’t be ready, perhaps, or it will be just reaching the state when it’s edible. If it’s not edible, though.. Sorry, it’s your problem”.

This is approximately how customers in the IT-sphere feel when they’re offered to start a job without estimations.

In the example above we’d ideally like to get an exact price for the steak. At the very least, it’d be fine if we just got a price range. This way we can check whether we want to go to this restaurant, choose a cheaper one, go get a cheeseburger or stay home and cook a salad.

Going to the restaurant without any understanding as to what to expect is not the decision that a person in the right mind will take.

I hope I could convince you that estimation is an important part of a decision making process on any project. The estimation can be as close or far from reality as possible, but it’s needed nevertheless.

Reasons for underestimation

Ignoring probability theory

Imagine the following situation. A developer is approached by a manager, and the manager would like to know how long it will take the developer to finish a task. The developer has done something like that in the past and can give the “most probable” estimation. Let it be 10 days. There’s a probability that the completion of the task will last for 12 days, but the chance is lower than that of 10 days. There’s also a chance that the task would be completed in 8 days but this probability is lower as well.

It’s often assumed that estimation for a task or a project is distributed according to the normal distribution law (read more about it here). If you show estimation distributions as a graph, you’ll get this:

X shows estimation while Y shows probabilities that the estimation will turn out to be correct and a task will consume the precise amount of time. In the center, you can see the point of the highest probability. It goes with our 10-day estimation.

The area under the curve shows a probability of 100%. It means that if we go with the most probable estimation, we’ll finish the project by the deadline with the 50% chance (the area under the graph before the 10-hour estimation is half of a figure, therefore it’s 50%). So, if we go with this principle, we’ll be able to only miss 50% of the deadlines.

This is only if the distribution of probabilities does go hand-in-hand with the normal distribution. In this case, the possibility of finishing a project earlier than a possible estimation equals to finishing it later than a possible estimation. However, it’s also normal that something goes wrong with the project, and we finish it later. Of course, a miracle can happen, and we finish earlier but what is the chance of that? In other words, the amount of negative possibilities is always higher than that of positive ones.

If we go with this idea in mind, the distribution will look like this:

For this to be easier to read, let me represent this information as a cumulative graph. It will show a possibility of finishing the project earlier than a deadline or just in time:

Turns out, if we take the “most possible” estimation in 10 days, the possibility of the task being completed in that period or earlier is less than 50%

Ignoring the current level of uncertainty

As we work on a project/task, we keep learning new information. We get feedback from the manager, designer, tester, customer, and other team members. This knowledge keeps renewing. We don’t know much about the project from the beginning, but we learn more as we go along, and we can mention exactly how long it took us once we’ve finished the project.

What we know directly affects how precise our estimation is.

Luiz Laranjeira’s (Ph.D., Associate Professor at The University of Brasilia) research also shows that the accuracy of estimating a software project depends on how clear the requirements are (Luiz Laranjeira, 1990). The clearer the requirements are – the more accurate the estimation is. Usually, the estimation isn’t clear because the uncertainty is involved in the project/task. Therefore, the only way of reducing uncertainty is by reducing it in the project/task.

Considering this research and common sense, as we decrease the uncertainty on a task/project, we increase the estimation accuracy.

This graph is here to make it easier to understand. In reality, the most possible estimation may change as uncertainty decreases.

Dependency between precise estimation and the project stage

Luiz Laranjeira went on with his research and figured out how numerically dependent estimation spread in on a project stage (level of uncertainty).

Taking optimistic, pessimistic and the most possible estimations (optimistic estimation is the earliest period of finishing the project out of all, while pessimistic is vice versa, the latest) and show how their ratios change over time, from start to finish of the project, we’ll get the following picture:

This is called a cone of uncertainty. The horizontal axis stands for the time between the start and the finish of the project. The main project stages are mentioned there. The vertical axis shows a relative margin of error in the estimation.

So, at the start of the initial concept, the most possible estimation may vary from the optimistic one by 400%. When the UI is ready, the spread of estimation goes between 0.8 and 1,25 relative to the most possible estimation.

This data can be found in the table down below:

Life-cycle stageoptimistic estimationpessimistic estimation
Initial concept0.25х
Business requirements (agreed definition of the product)0.5х
Functional and non-functional requirements0.67х1.5х
User Interface0.8х1.25х
Thoroughly thought realization0.9х1.15х
Finished product

It’s very important to note that the cone doesn’t get narrower as time goes by. For it to narrow, one needs to manage the project and take action to lower uncertainty. If one doesn’t do that, they’ll get something like this:

The green area is called a cloud of uncertainty. The estimation is subject to major deviation up to the very end of the project.

To move on the cone to the most-right point where there’s no uncertainty, we need to create a finished product :). So, as long as the product is not ready, there will always be uncertainty, and the estimation can’t be 100% precise. However, you can affect the estimation accuracy by lowering uncertainty. With this, any action targeted at lowering uncertainty also lowers the estimation spread.

This model is used in many companies, NASA included. Some adapt it to consider volatility in requirements. You can read about that in detail in “Software Estimation: Demystifying the Black Art”.

What is a good estimation?

There are plenty of options to answer this question. However, in reality, if the estimation deviates by more than 20%, the manager doesn’t have a room for maneuver. If the estimation is somewhere around 20%, the project can be finished successfully by managing functionality, deadlines, team size, etc. It does sound logical, so let’s stop at this definition of good estimation, for example. This decision has to be taken on the organizational level. Some risk and a 40-50% deviation is OK for them; others see 10% as a lot.

So, if out estimation differs from the actual result by not more than 20%, we consider it good.

Practice. Estimating a project on various stages

Let’s imagine that a project manager has approached you and asked to estimate a function or a project.

To start with, you have to study available requirements and figure out the life-cycle stage of a project definition.

What you do next depends on the stage you’re on:

Stage 1. Initial concept

If a manager approaches you and asks how long it will take to create an app where doctors will consult patients, you are on Stage 1.

When does it make sense to make estimations on this stage?

On a pre-sale stage. When you need to realize whether it’s worth it to further discuss the project. All in all, it’s better to avoid estimations on this stage and try to lower the uncertainty as soon as possible. After that, we can move on to the next stage.

What do you need to estimate on this stage?

Actual labor time data on a similar finished project.

What tools are the most suitable for this stage?

  • An estimation by analogy

Estimation algorithm

Actually, estimating the project on this stage is an impossible task. You can only see how long a similar project took to launch.

For example, this is how you could put your estimation into words: “I don’t know how long this project will take as I lack data. However, project X which was similar to this one took Y time. To give at least an approximate estimation, it’s imperative to make requirements clearer”.

If there’s no data from similar projects, then lowering the uncertainty and moving to the next stage is the only way to estimate here.

How to move to the next stage?

For this to happen, the requirements must be clarified. You need to understand what the app is for and its functionality.

Ideally, one should have skills in gathering and analyzing requirements.

To improve that skill, it’s recommended to read “Software requirements” by Karl Wiegers and Joy Beatty.

To gather preliminary requirements, you might use this questionnaire:

  • What’s the purpose of the app? What problems will it solve?
  • What is the target audience? (for the task above that could be doctor, patient, administrator)
  • What problems will each type of users solve in the app?
  • What platforms is the app for?

After figuring these things out, you will have an image of the app in your head with all the necessary information. With this, we’re moving to Stage 2.

Stage 2. An agreed definition of the product

We have an understanding here, although not very detailed, about what the app will do and what won’t. 

When does it make sense to make estimations on this stage?

Again, on the pre-sale stage. Right when one needs to decide whether it’s worth it to complete the task or project, whether they have enough money, whether the deadlines are affordable. You need to check if the value that the project brings is worth the resources that need to be involved.

What do you need to estimate on this stage?

Quite a few finished projects and their estimations OR huge experience in the area of development to which the project is related. These two combined would be even better!

What tools are the most suitable for this stage?

  • An estimation by analogy
  • A top-to-bottom estimation

Estimation algorithm

If there was a project like this before, the approximate estimation would be the time spent on that project.

If there is no data on projects like that, you need to split the project into the main functional units, then estimate every block according to those that were done on other projects.

For example, with the app where the doctors would consult patients, we could have got something like that:

  • Registration
  • Appointment scheduling system
  • Notification system
  • Video consultation
  • Feedback system
  • Payment system

You could estimate the “registration” block by using something similar from another project and for the “feedback system” a block from a different project.

If there are blocks that were never done before or they lack data, you can either compare the necessary labor time against other blocks or reduce uncertainty and use the estimation method from the next stage.

For example, the “feedback system” module might seem twice as difficult as the “registration” module. Therefore, for the feedback, we could get an estimation twice as high as the registration.

The method of comparing one block against the other is not exactly precise, and it’s better used in the situation where the number of the blocks that were never done isn’t higher than 20% of the blocks that do have historic data. Otherwise, it’s just a guess.

After this, we summarize estimation of all blocks, and it will be the most possible one. The optimistic and pessimistic estimations can be calculated using the coefficients appropriate for the current stage – x0,5 and x2 (check the coefficient sheet).

Ideally, you should let your manager know what’s going on, and they will have to deal with it.

If the manager can’t deal with it and asks for one, single number, there are ways to do that.

How to calculate one estimation out of three? It will be answered down below in the corresponding chapter.

How to move to the next stage?

Prepare a full list of requirements. There are quite a few documentation ways, but we’ll look into a widely used one with a User Story.

We need to understand who will be using each block and what they’ll be doing with the blocks. 

For example, for the “feedback system” block we would end up with these bullet points  after gathering and analyzing requirements:

  • A patient can check all feedback about the chosen doctor
  • The patient can leave feedback for the doctor after a video consultation with him
  • The doctor can see feedback from the patients
  • The doctor can leave a comment on feedback
  • An administrator can see all feedback
  • The administrator can edit any feedback
  • The administrator can delete feedback

You will also need to collect and write down all requirements that are not functionality-based. To do that, use this check-list:

  • What platforms is it for?
  • What operating systems need to be supported?
  • What do you need to integrate with?
  • How fast is it supposed to work?
  • How many users at the same time can use the tool?

Clarifying this stage will move you to the next one.

Stage 3. The requirements are gathered and analyzed

This stage has a full list of what each user can do in the system. There is also a list of non-functional requirements.

When does it make sense to make estimations on this stage?

When you need to give an approximate estimation for the project before you begin working with the Time & Materials model. The estimation of tasks from this stage can be used to prioritize some of them on the project, to plan the release dates and the whole project budget. You can also use those to control the team’s efficiency on the project.

What do you need to estimate on this stage?

  • The list of functional requirements
  • The list of non-functional requirements

What tools are the most suitable for this stage?

  • An estimation by analogy
  • A top-to-bottom estimation

Estimation algorithm

You need to decompose each task (split it into components). The smaller the components are, the more precise will the estimation be.

To do it on the best of your abilities, you need to represent everything that needs to be done on paper.

For example, for our User Story that goes like “a patient can see all feedback about the chosen doctor”, we could get something like this:

We split the task here into three parts:

  • Create infrastructure in the database
  • Create the DAL level for data samples
  • Create a UI where the feedback will appear

If you could, you can write down the UI functionality and approve it with whoever asks for estimation. It will eliminate lots of questions, make the estimation more precise, and be a good quality of life change.

If you want to improve your interface design skills, it’s recommended to read two books: “The Humane Interface” by Jef Raskin and “About Face. The essentials of interaction design” by Alan Cooper.

Then you need to imagine what exactly will be done for each task and estimate how long it will take. Here you have to calculate time, not guess it. You have to know what you will do to finish each subtask.

If there are tasks that take more than 8 hours, split them into subtasks.

The estimation received after having done this can be considered optimistic as it most likely uses the shortest path from point A to point B, given that we haven’t forgotten anything.

Now it’s about time we thought about things that we’ve probably missed and correct the estimation accordingly. Usually, the checklist helps here. This is an example of such a list:

  • Testing
  • Design
  • Test data creation
  • Support for different screen resolutions

After completing this list, we have to add the tasks we might have missed to the task list:

Go through each task and subtask and think about what could go wrong, what is missed. Oftentimes, this analysis reveals things without which you can’t end up with a best-case scenario. Add them to your estimation:

After you calculate this, too, your estimation will be even closer to the optimistic one than to the most possible one. If we take a look at the cone, the estimation will be closer to its lowest line.

The exception here might be if you’ve done a similar task before and can speak with authority that you know how it’s done and how long it takes. In that case, your estimation would be called “the most possible” and it’d go along with the 1x line on the cone. Otherwise, your estimation is optimistic.

The other two estimations can be calculated with the coefficients according to this stage: x0,67 and x1.5 (check out the coefficient table).

If you calculate the estimation from the example above, we’ll get this:

  • Optimistic estimation: 14 hours
  • The most possible estimation: 20 hours
  • Pessimistic estimation: 31 hours

How to move to the next stage?

By designing the UI. Creating wireframes would be the best way to go.

There are multiple programs for that but I’d recommend Balsamiq and Axure RP.

Prototyping is another huge topic that is not for this article.

Having a wireframe means that we’re on the next stage.

Stage 4. The interface is designed

We have a wireframe here as well as the full list of what each user will do in the system. We also have a list of non-functional requirements.

When does it make sense to make estimations on this stage?

To create an exact estimation by the Fixed Price model. You can also do that for everything that was mentioned in the previous stage.

What do you need to estimate on this stage?

  • Prepared wireframes
  • A list of functional requirements
  • A list of non-functional requirements

What tools are the most suitable for this stage?

  • An estimation by analogy
  • A top-to-bottom estimation

Estimation algorithm

The same as in the previous stage. The difference is in accuracy. Having a planned interface, you won’t have to think as much and the possibility of missing something is lower.

How to move to the next stage?

Design the app architecture and thoroughly think about the realization. We won’t check that option as it is used quite rarely. With that being said, the estimation algorithm after thinking about architecture won’t differ from one on this stage. The difference is, once again, in accuracy increase.

Retrieving one estimation from the range of estimations

If you have the three types of estimation ready, we can use the knowledge by Tom DeMarco to retrieve one estimation. In his book “Waltzing with bears” he mentioned that absolute possibility can be obtained by integrating the area under the curve (in the graph we had before). The original calculation template can be downloaded from here or from here without registration. You need to insert three numbers in the template and receive a result as a list of estimations with their corresponding probabilities.

For example, for our estimations of 14, 20, and 31 hours we’ll have something like this:

You can choose any probability you deem decent for your organization, but I’d recommend 85%,

Don’t know how to estimate? Speak up!

If you don’t know what you’re asked or how to implement the functionality you need to estimate? Let your manager know, give him an approximate estimation, if that’s possible, and suggest actions that will make the estimation more precise.

For example, if you don’t know whether the technology works to finish the task, ask for some time to create a prototype that will either confirm your estimation or show what you’ve missed. If you are not sure that the task is doable, say that from the beginning. These things need to be confirmed before you’ve put their weight on your shoulders.

It’s very important to provide a manager with this information, otherwise, he can blindly trust you and have no idea that there’s a chance of missing the deadline by 500% of the time or simply not finish the product with the technology or requirements you have.

A good manager will always be by your side. You and he are in the same boat, and sometimes his career depends on whether you’ll finish on time even more than yours.

Doubts? Don’t promise

Many organizations and developers help their projects fail by taking on responsibilities too early on the cone of uncertainty. It’s risky as the possible result jumps between 100% and 1600%.

Efficient organizations and developers postpone decision making up until the moment when the cone is narrower.

Usually, this is normal for organizations that are on the more mature CMMI module level. Their actions to make the cone narrow down are clearly stated and are followed.

You can see the quality of estimations and its increase in the projects of the U.S. Air Force when they moved to the more mature CMMI level:

There’s something to think about here. Other companies’ statistics confirm this correlation.

Even here, accuracy of the estimations can’t be achieved only with estimation methods. It’s inextricably linked to the efficiency of project management. It doesn’t depend only on developers, but also on project managers and senior management.

Conclusion

  • It’s nearly impossible to give an absolutely correct estimation. You can, however, affect the range in which the estimation will fluctuate. To do that, try and lower the uncertainty level on the project
  • Making estimation be more accurate can be achieved through splitting tasks into components. As you decompose things, you’ll think what and how you will do things in details
  • Use checklists to lower the possibility of missing something as you estimate
  • Use the uncertainty cone to understand the range where your estimation will most probably fluctuate
  • Always be comparing the given estimate with the time that was actually spent on a task. It will help you improve your estimation skill, understand what you’ve missed, and use it as you move further.

Useful books

There is a lot of literature on the topic but I’ll recommend the two books that must be read.

  • Software Estimation: Demystifying the Black Art by Steve McConnell
  • Waltzing With Bears: Managing Risks On Software Projects by Tom DeMarco and Timothy Lister.