SOFTWARE DEVELOPMENT TIME AND COST ESTIMATES – REDUCING PROJECT COMPLETION UNCERTAINTY
Any software development estimate is based on a combination of effort, time, and costs associated with the project scope. The crux is finding a balance between the client’s or manager’s requirements and the team’s ability to address these requirements in estimating a proposed project.
The two main parameters that stand at the center of project estimation are the time needed for completion and the costs of development work. Based on that, several techniques for software development estimation could be used, including analogy estimation, expert estimates, bottom-up estimates, three-point estimates, parametric estimates and use case points.
Depending on the project stage, different estimation techniques could be employed. For example, analogy estimation and estimates by experienced architects suit best when assessing the feasibility of the project, and at the early project initiation stages. Similarly, bottom-up task-level estimates and estimations based on the historical data from previous iterations work better at the building-time and sprint-planning stages.
Source : Medium.com
Agile and waterfall projects require different estimation techniques
Different management strategies presume different software development estimation techniques. Experts opine that most projects can be assessed based on traditional/conventional (mostly waterfall) and agile methods. Traditional methods are usually based on bottom-up estimation, while agile methods are usually based on top-down assessment.
Source : Altexsoft
Bottom-up methods require a period from several weeks to several months to define the detailed requirements of the project. Such methods identify tasks and resources required for project completion to estimate the delivery date and budget. The idea is to plan ahead, while the top-down approach is about navigating in the process.
In contrast to the bottom-up method, the top-down technique identifies key project points and starts with them. The planning process involves multiple iterations that allow the project to be broken down into smaller subtasks and the assessment to be adjusted during project implementation.
Each of these methods has its pros and cons. For example, bottom-up techniques help reduce uncertainty about the project development process but have inbuilt risks of over- and underestimation. Top-down methods allow the team to quickly adjust and change development directions, but bear greater uncertainty for clients and managers in terms of time, costs and effort required to deliver the project.
As a result, each of the two methods is suitable for different project types, as shown in the table below.
Source : IBM
On the one hand, assessment methods and techniques help address, at least to some extent, the uncertainty associated with the development process. On the other hand, there are no one-size-fits-all solutions for software development estimation, as each project is unique, each development team has different amounts of resources available to it, and each client has different requirements based on the available budget and timeframe allocated for project completion.
This means that software estimation should be considered as an orientation to the project’s scope that can be adjusted in the development process, rather than a document with final obligations that have to be followed by all means.
Effort estimation is a way to make agile projects more predictable
Estimation issues we discussed above touched upon the time, costs and uncertainty associated with project delivery. There is another element that is important when assessing projects that follow agile methodology — the effort required to deliver the work.
In fixed-price projects, the client pays for the number of tasks that have to be completed by the development team. This works well for projects that use traditional waterfall methods for management, where the specifications are more or less clear and the amount of effort required to deliver each task is more or less known based on analogy or historical cases.
However, for innovative projects with unclear input and specifications, the estimation of effort can often not be done right from the start. Such projects possess a greater degree of uncertainty, as additional information only becomes available during subsequent iterations. This lack of information makes it difficult to identify how long it will take to complete each task and how much it will eventually cost.
This is where software effort estimation techniques come into play. Agile development is collaborative work, which means that project tasks are usually assigned to a team and divided among team members in the process (in contrast to the waterfall, where individual contributors are identified at the beginning). Researchers identify three main effort-estimation techniques: Planning Poker, Constructive Agile Estimation Algorithm and AgileMOW.
Planning Poker is based on a collective assessment of story points by experts who use cards with Fibonacci numbers (1, 2, 3, 5, 8, 20, 40, 100) to represent their estimates. Smaller numbers represent less uncertainty in effort assessment, while bigger numbers represent more uncertainty.
The overall effort required to complete a set of tasks is calculated based on the average estimate by all experts involved. If the estimates differ significantly, the marginal estimates are discussed further until a collective agreement on the proposed effort is reached.
Constructive Agile Estimation Algorithm consists of early estimation and iterative estimation. Early estimation identifies the initial scope to draw the initial budget, while iterative estimation is done at the start of each iteration to include new requirements and make budget adjustments.
The algorithm is based on vital factors (project domain, performance, configuration, data transaction, complex processing, ease of operation and security) that are assessed and used for estimation. Each of these factors is evaluated as low, medium or high using Fibonacci numbers. The final estimate is made by multiplying these evaluations to the story point.
AgileMOW was introduced to estimate the delivery of web applications. It uses both expert judgment and an algorithm to estimate effort. This method is based on evaluating the following factors: communication skills, the proximity of team, feedback, courage, management skills, technical ability, reliability, ease of use and early delivery.
The algorithm is based on the Agile COCOMO II (Constructive Cost Model) and makes estimations by analogy, which allows cost and effort for the proposed project to be predicted based on previously gathered data about the key factors mentioned above and their weight in the project. The model is used to estimate the number of people required to complete a project in a certain amount of time, which helps to assess costs associated with the effort required for completion of project tasks.
To summarize, Planning Poker is useful because it provides insights from several experts as opposed to a single project manager’s vision. The Constructive Agile Estimation method estimates effort by identifying the factors that are critical for task completion at the early stages of the project and also at each iteration stage to make adjustments. AgileMOW is capable of providing important insights into the project scope and effort based on data about similar cases, which could make the delivery process more predictable.
Each of these methods can help in agile project effort assessment by reducing uncertainty. Nevertheless, none of them is ideal or better than the others, since any estimation is a prediction that can only be accurate to a certain degree.
Conclusion: Estimates are predictions, not commitments
Software development estimation is a prediction that accounts for time, costs, resources and effort required to address the project scope. In this article, we talked about the general techniques used in estimating projects that use both traditional and agile methodologies.
Most commonly, waterfall projects employ a bottom-up approach to estimation, while agile projects use the top-down technique. Nevertheless, there is no single ideal solution to software estimation because any estimation is a prediction that cannot be 100% accurate.
Fixed-price projects with clear input allow tasks and work roles to be distributed at early development stages, which is usually associated with waterfall methodology. Agile projects are usually estimated in terms of effort, rather than in total time and costs, because project requirements have to be adjusted in the process.
This takes us back to the argument that software estimation is more of an orientation rather than a final and unchangeable set of commitments, because it is not possible to account for all the risks associated with the development process. This makes a degree of uncertainty the central element of any software estimation.
Article by
