There are well-known guidelines on how to amaze the world with your brand new application:

• First of all, it is time-to-market. The sooner you publish your MVP, the better. MVP (or Minimal Viable Product) is the version of your product which allows you to evaluate the feedback you get from and about your customers with minimal efforts. In today’s fast-paced world, you just can’t waste weeks or months planning the design and detailed full-scope specification, and then the rest of the year working on development! Our belief is that it shouldn’t take more than 4 weeks from the original idea to your first version MVP. That should be the term to bring your new app live! Now or never!
• Incremental business value. Be sure you iteratively bring new business value with every new update of your application.
• Priority. Start from most important features and leave «nice-to-have» for later.
• Design. From the really first version, your app should be attractive and brilliant! You should certainly consider the whole venture as a design driven activity.
• Listen to your users. You probably have a clear picture on how and what your app should do. However, you are not the only one who will be using the application, it will be used by other people! So, ask, listen and follow your audience.

In summary, all that means you can expect a lot of changes from your initial concept to the final product. It could happen that, after several versions, the layout and purposes of your app will be absolutely different from what you had imagined in the beginning. In that case, it is recommended that you follow the changes and set up development project from a change driven and iterative perspective. In other words, you need to take an agile approach (you can find more about agile approach here and here).

On the other hand, a change driven approach means that the scope is not fixed and, therefore, the whole task cannot be estimated accurately. How do we deal with the estimation of the entire project when the scope is not fixed?

Is there a way to stay agile and change driven, and still get the appropriate estimate and plan a budget?
Yes. We believe there is a way to conciliate both things.

First, let’s consider the most popular estimation methods currently used in software development.

UCP

The Use Case Points (UCP) method comes from and is based on UML – Unified Modeling Language. UCP operates with Use Cases as major estimation objects. The method takes into account not only efforts (points) needed to develop a feature but also adjustments like type of user interface, technical and environmental factors, and types of actors. Even though UCP works fine and gives a very close estimate, the method presents some usage limitations. You can find more about the UCP here and here.

Function Point Analysis (FPA)

The FPA method has similar concepts to the UCP. The FPA groups all features into five categories: Enter points, Exit points, Requests, Internal files and External interfaces. Then, every feature is assessed and assigned a functional point adjusted with its complexity. You can find out more about it here.

PERT

The Program Evaluation and Review Technique (PERT) uses a three points estimate approach. The method evaluates every task using the formula E = (O + 4M + P) /6, where:

E …  stands for Estimate;
O …  is Optimistic estimate or the best-case estimate;
P …  is Pessimistic estimate or the worst-case estimate;
M …  is most likely estimate.

PERT works fine on most cases. You can find out more about it here and here.

PROBE

The Proxy Based Estimating (PROBE) method is based on the assumption that similar tasks (products, components) require more or less the same efforts. Later, when an estimate for a new application is needed, people usually look for similar products or components in the past and use that information of proxy case as basis for new estimation using PROBE technique. Of course, that method require a history of delivered projects. You can find out more about the PROBE method here.

PLANNING POKER

Planning poker is a relatively new type of estimation method, often used in SCRUM, KANBAN and other agile processes. The method has three major characteristics:

• It does not consider absolute efforts for tasks (stories), operating with the relative story points
• It is a team based activity, so everyone participates in the estimate process
• The method uses “gamification” for estimation process

The planning poker is an easy and very effective technique, which brings not only an estimate achieved with consensus but also involves a whole team to process. Moreover, there are several online tools available to make the planning game easy and fun. More about planning poker here.

Note that the above list of estimation methods is far from complete. You can use others options, such as Source lines of code, COCOMO, Cosmic software sizing and so on.

Open Estimation by Edgica

At Edgica, we use the UCP and the Planning Poker methods the most. However, choosing which method to use depends on each particular case. For more complicated and larger projects, following the UCP or PERT techniques makes more sense. For relatively small apps, PLANNING POKER seems to be more advantageous. Regardless of the method used, we provide three estimates:

• MIN – Minimal efforts needed to develop the scope
• MP – Most probable efforts needed
• MAX – Maximum efforts needed

In this way, instead of having just one fixed cost estimate, we stay open and provide you with a range of efforts needed. In other words, you will be able to know that it will cost more than the MIN, probably around MP, and less than the MAX estimate.

Now, think about what is the most probable estimate that software providers consider when they announce only one estimate as the fixed cost for the task? The MIN, MP or MAX? Of course, since their intention is to consider all possible risks and challenges, and include them into fixed cost, they probably announce the MAX or close to it.

However, isn’t it better to consider all three estimates – minimal, most probable and maximum – in order to plan and control the development of the project?

Furthermore, as part of the estimate, we transparently provide you with a list of assumptions, major risks and challenges, basic planning, approach, and team roles. In this way, you cover all aspects of your future project and make the right decision. That is what we call an open estimate.

We really do like hearing your thoughts on the subject, so drop us a line and let us answer all of your questions!