What’s the point of Software Estimates in Agile Projects?
By Amer Wilson
So before you commission anyone to do any job, you ask for an estimate right? That’s just basic 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 one 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. Estimating takes tons of time.
Software costs estimation is integrally 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 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 a good quality software is like the livelihood for senior engineers; coming up with creative products becomes a much harder endeavor, overall.
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 cost of the Agile Projects? When can we deliver/launch? What shall be the ROI? Etc.
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:
- Business and customer requirements evolve. More often than not, functionality or scope will change. More features and needs become 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 an increased cost, 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. E.g. your competitor might launch your product’s rival before you do, thus losing you any competitive advantage in the market.
Many other negative outcomes of variable time and cost have been known to arise as well.
Agile Contracts for Software Projects
Variable cost and time means employing people for longer. Adding in more team members, leads to increase in cost to deliver the same business value. These should be avoided, which is why Agile follows the practise of fixed time, fixed cost and allowing for scope to be the variable component.
So Agile contracts focus on the following:
- Fixed cost– The project is firstly broken down into miniature releases. Each of these is given a fixed cost to complete in. when a release gets completed, future releases are gives a cost estimate based on that and so on. This avoids any hassle, and customer can evaluate these release and change/add more features accordingly.
- Early termination– A customer can to 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. 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 can be taken out. As long as the value stays the same, 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 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 other, preferred one. Scope is a variable here, but 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 understand their views and experiment techniques, 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, to avoid any big risks and wastage.
The following steps are taken in expanding an estimate and price of the project:
1. 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? Etc. These shall help you set the initial scale of the project. Then go on to defining the high level features that will fulfil your customer’s main needs. This list is often referred to as “User Stories”.
Further, you can also make use of the MoSCoW analysis. M stand for Must, which are set of features that are 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 significance and might not get you any ROI. W are 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.
To proceed with a project, it is necessary to have well informed data: cost and duration. These are the minimums you need to ask yourself: What will be the cost required to finish up? When can we launch our product? Etc.
When the above details are decided, we can then 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, because otherwise would mean a fixed scope. Defining a proposal is the first step in estimating the duration and cost of a project.
3. 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, main acceptance criteria is 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 means 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 which, 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 estimate required to deliver the product. The customer and the team, work together to create a release plan. The plan gives an insight on 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.
E.g. we take our story points let’s say, 100. And 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 complete by a given date, not forgetting to add time to manage any risks involved.
For all of the above, good quality communication and collaboration between is required to derive a release plan that is realistic and acceptable to the customer.
4. 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.
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. Ultimately resulting in a decision to proceed with the project. Follow the guidelines to enroute a successful journey of a product to life.
Rolustech has a decade long experience in successfully implementing CRM systems for its global clientele.