What’s the Point of Software Estimates in Agile Projects?

Last Modified Date

So before you commission anyone to do any job, you ask for an estimate, right? That’s just common sense. The same way, nearly every software project starts off with one question: How much is this going to cost? Another way could be; how long will this take?

Determining the two factors mentioned above in software development is some of the hardest things to do. Should it be so hard? The answer is not straightforward.

There are usually two common replies to these questions; “we don’t know”, or “let us make an estimate and get back to you.”

Customers don’t like the first reply, and the technical lot aren’t very happy with themselves giving the second reply to the customers either at times. Estimation takes tons of time.

Software cost estimation is essentially difficult. Humans are known to be terrible at predicting absolute outcomes.

Every project is unique in its own way, with the innumerable parameters that form its existence. Often, those seemingly tiny problems on the surface turn out to be harder or technically challenging when it comes to implementation. Along with these, there are multiple ‘unknown’ factors that pop up as time passes by during implementation.

Whether you are a developer or a user, everyone has their own set of knowledge, expectations, attitude to risk, and their ability to adapt.

Implementing good quality software is like the livelihood for senior engineers; coming up with creative products becomes a much harder endeavor, overall.

Agile Projects

In software, duration and cost are the key components when making business decisions. This applies to all cases from creating a startup to enabling your business to perform better. Timing, ROI, and profit, among other things, can make or break your business.

At any point soon, you shall be asking yourself questions like, can we predict the cost of the Agile projects? When can we deliver/launch? What shall be the ROI?

So, let’s explore how Agile project estimation and software development costs work.

Traditional Contract Pricing and Estimation

Traditionally, using non-Agile practices, software projects have a fixed scope and variable time and cost for the project. This can cause problems:

  • Businesses and customer requirements evolve. More often than not, functionality or scope will change. More features and needs are identified throughout the lifecycle of a project and they need to be implemented.
  • No fixed cost means losing control on the ROI that you’re trying to achieve. Risk factors and changing scope can lead to increased costs, which could mean doing more work with more team members in the same time frame. This can be expensive.
  • No fixed time estimate can make you lose a decent position in the market. For example, your competitor might launch your product’s rival before you do, resulting in your loss of any competitive advantage in the market.

Many other negative outcomes of variable time and cost have been known to arise as well.

Software Estimates in Agile Projects 3

Agile Contracts for Software Projects

Variable cost and time mean employing people for longer. Adding in more team members leads to an increase in the cost of delivering the same business value. These should be avoided, which is why Agile follows the practice of fixed time, fixed cost and allows for scope to be the variable component.

So Agile contracts focus on the following factors.

Fixed Cost

The project is, firstly, broken down into miniature releases. Each of these is given a fixed cost to be completed in. When a release is completed, future releases are given a cost estimate based on that and so on. This avoids any hassle, and the customer can evaluate these releases and get features changed/added accordingly.

Early Termination

A customer can terminate the project if the product has delivered ample ROI or cannot deliver any further. This is allowed at any time, as long as the team and the customer have had a good relationship. The customer gets done with the project early this way, the team gets paid a decent percentage of the remaining contract and they don’t have to retain more team members for a longer time.

Flexible Changes/Features

Change can happen throughout the implementation of the Agile project. Changes can be made based on relevant data and feedback, to ensure that the right product is delivered. At the end of an iterative cycle, new additions can be made or old ones are taken out. As long as the value stays the same, the cost does not increase. New features also come and go. These features can be made part of the new release or revert to time and materials.

Ranged Estimates

There are two ways to range estimates, based on a range of duration or a range of features. A range of duration allows for an estimate to say that a release can take up to 8 to 12 weeks, provided the set of scope. Range of features is the preferred one. The scope is a variable here, but the main focus is to deliver value within the allocated time frame.

Approach We Follow on Cost and Estimation

We work closely with our customers and engineers to understand their views and experimentation techniques, and to gain confidence in project duration and costs. We work to gradually improve our planning process from the high level down to the grass-root level, trying to avoid any big risks and wastage.

The following steps are taken in expanding an estimate and price of the project.

Setting the High-Level Scope

Start off the project by listing a set of high-level and essential features that guide the direction of the project, based on the objectives.

Firstly, set your vision and objectives straight, like what do we need to build? What business objectives are we trying to achieve? These shall help you set the initial scale of the project. Then we go on to defining the high-level features that will fulfill your customer’s main requirements. This list is often referred to as ‘User Stories’.

Further, you can also make use of the MoSCoW analysis. M stands for ‘Must’, which is the set of features that are a must to make the product viable and can help engage users. S stands for ‘Should’, where the features are good enough for the product, but not a priority and can be done later. C stands for the list of ‘Could’ items, where the features have little or no significance and might not get you any ROI. W is the Won’ts, which are totally out of scope for the release.

Identifying the above can set the initial scale and size of the product for the future.

Software Estimates in Agile Projects 4


To proceed with a project, it is necessary to have sufficient data; cost and duration. This is the minimum you need to ask yourself: What will be the cost required to finish up? When can we launch our product?

When the above details are decided, we can then put forward a decent proposal. Best suitable developers are assigned to the project, than can work well in collaboration with the project manager to derive the workable requirements and, an estimated duration required to deliver the scope set, and an estimated cost to complete the project.

Set of scope and features is kept vague, otherwise, a fixed scope would be required. Defining a proposal is the first step in estimating the duration and cost of a project.

Release Planning

The next step in this estimation process is the release planning. This will be us deciding the range of features that can be delivered in a given time frame. This can be done by taking into account the feature list, scale of the project and how quickly can the developers finish the required work.

First, make a set of features or user stories that are required for the product. These are then broken down into meaningful items. Details are not considered at this stage, the main acceptance criteria are the main focus.

After the user stories are defined into meaningful items, estimates are made on these items. An agreed number is assigned to each item based on its size and complexity. ‘Planning poker’ and ‘ideal days’ techniques can be used to make estimates.

The end of this process will determine the size of the project. The size is determined by adding up all the story points from the items, e.g. 100 story points mean the size of the project is a 100 story points.

Next comes prioritization. We need to identify what is most valuable and required for the project to achieve the desired results. The item at the top of the list will be considered most important.

Prioritization is an important step in the planning process. After this step, we know what is important to the customer and in which order to complete work and meet expectations.

Next comes release planning. We determine the time required to deliver the product. The customer and the team work together to create a release plan. The plan gives an insight into how the project will align with the customer’s plans and needs.

Before we start on this plan, we need to set the definition of “work done.” This shall be the criteria that the customer will accept as complete and releasable.

For example, we take our story points, say, 100. With the team size and work speed, we estimate that a total of 10 points can be done per release/iteration. That would result in a total work of 10 weeks or 10 iterations. We add to that a sprint 0 of 2 weeks and a release preparation of another two weeks. In total, our project length is 14 weeks.

Alternatively, we can work around like that if the project must be completed by a given date, not forgetting to add time to manage any risks involved.

For all of the above, effective communication and collaboration is required to derive a release plan that is realistic and acceptable to the customer.

Fixed Price Contract

Once the release plan is done with, we are able to create a quote for a fixed price contract. The quote is delivered to the client, along with a statement of work and an agreed payment schedule. With proper communication and collaboration, we are able to deliver the quote with confidence that the project will be delivered on time and on budget.

It’s a Wrap!

All of the approaches and techniques mentioned above are designed to build trust and confidence between the team and the customer on how long and how much it will take to build a software product. This would, ultimately, result in a decision to proceed with the project. Follow the guidelines to start a successful journey of bringing a product to life.

Rolustech has a decade long experience in successfully implementing CRM systems for its global clientele.

Rolustech is a SugarCRM Certified Developer & Partner Firm. We have helped more than 700 firms with various SugarCRM Customization, Migrations and Integrations. Contact us today for your FREE Consultation Session. We will be happy to assist you!

Related Posts:



Need Help? Get Free Consultation

By clicking you agree to our Terms and Conditions

Send me news and updates

Get in touch

Contact Information

Looking For a Job ?