Estimate in the Agile World

Some Agile organizations deliver software very effectively, while others do not. Why? What is the key to effective Agile delivery? At DCG, we believe the keys are:

  1. A clear focus on value
  2. Knowledge of the organization’s capabilities and rate of delivery

All software is developed to ultimately increase profits or to make a service more effective. This is the value that the business cares about; thus, development should always maintain a focus on this as well, which can be achieved via estimation.

Value-based estimating at the project level, and quality, sprint-focused estimating in development teams, can work together to ensure delivery for successful business software development in an Agile environment.

Download, "Estimating in an Agile World - Delivering Value" for more information on how this can be done.

Download Now.

Written by Default at 05:00
Categories :

How Do We Know If We Are Getting Value for Our Software Vendors?

(You can download this report here.)

Scope of this Report

Discuss what is meant by value, the process of sizing and estimating the software deliverable and the benefits of those results

  • What is “Value”?
  • Functional Value
  • More on the estimation process
  • Case study example
  • Conclusion

What is “Value”?

We can look at value for software development from vendors in terms of how much user functionality is being delivered by the software vendor. In other words, how many user features and functions are impacted as a result of a project. We can also consider whether the software deliverables were completed on time and on budget to capture “value for money” and the monetary implications of timeliness. Finally, we can see if the software project delivered what was expected from a user requirements’ perspective and if it meets the users’ needs.

This last, more subjective, assessment of value gets into issues of clarity of requirements and the difficulties of responding to emergent requirements if the initial requirements are set in stone. It is outside the scope of this report but we believe the best way to address this issue is through Agile software development which is covered in several other DCG Trusted Advisor reports.

Functional Value

To quantify the software, we must first size the project. Of course, there are several ways to do this with varying degrees of rigor and cross-project comparability. Function Points and Story Points both have sizing perspectives that take a user’s perspective of the delivered software. Since Function Points Analysis is an industry standard best practice sizing technique we find that it is used more often for sizing at this Client-Vendor interface.

Function point analysis considers the functionality that has been requested by and provided to an end
user. The functionality is categorized as pertaining to one of five key components: inputs, outputs,
inquiries, interfaces and internal data. Each of the components is evaluated and given a prescribed
weighting, resulting in a specific function point value. When complete, all functional values are added
together for a total functional size of the software deliverable. After you have established the size of the software project, the result can be used as a key input to an estimating model to help derive several other metrics that could include but are not limited to cost, delivery rate, schedule and defects. A good estimating model will include industry data that can be used to compare the resulting output metrics to benchmarks to allow the client to judge the value of the current software deliverable under
consideration. Of course, there are always mitigating circumstances but at least this approach allows for an informed value conversation (which may result in refinement of the input data to the estimating

5 Key Components of Function Point Analysis

Of course, if you can base your vendor contract even partially on a cost per function point metric, this provides an excellent focus on the delivery of functional value although it is wise to have an agreed independent third party available to conduct a function point count in the event of disputes.

More on the Estimation Process

We have mentioned the importance of the estimation model and the input data in achieving a fair assessment of the functional value of the delivered software. We have also hinted that these will be issues to be discussed if there is disagreement between client and vendor about the delivered value. Hence, it is worth digging a little deeper into the estimation process.

The process for completing an estimate involves gathering key data that is related to the practices, processes and technologies used during the development lifecycle of the software deliverable. DCG analyzes the various project attributes using a commercial software tool (e.g. SEER-SEM from Galorath), assessing the expected level of effort that would be required to build the features and functions that had to be coded and tested for the software deliverable. The major areas for those technical or non-functional aspects are:

  • Platform involved (Client-server, Web based development, etc.)
  • Application Type (Financial transactions, Graphical user interface, etc.)
  • Development Method (Agile, Waterfall, etc.)
  • Current Phase (Design, Development, etc.)
  • Language (Java, C++, etc.)

Sophisticated estimating models such as those built into the commercial tools considers as well that are too numerous to mention include numerous other potential inputs including parameters are related to the personnel capabilities, develop environment and the target environment.

Given the size of the software deliverable and the complexity of the software deliverable represented by some of all of the available input parameters, we also need to know the productivity of the software development team that is developing the software. This can be a sensitive topic between Client and Vendor. We have often seen that the actual productivity of a team might be different from the reported productivity as the Vendor throws people on the team to make a delivery date (bad) or adds trainees to the team to learn (good) – mostly, for value purposes, the Client only cares about the productivity that they will be billed for!

Once we have established the development team’s rate of delivery or functions points per effort month, we can then use that information along with all the previous information (size, complexity) to deliver the completed estimate.

The end result of the sizing and estimating process would show how long the project will take to complete (Schedule), how many resources will be needed in order to complete (Effort) and the overall cost (Cost) of the software deliverable.

Sizing and Estimating Process

Case Study Example

DCG recently completed an engagement with a large global banking corporation who had an ongoing engagement with a particular vendor for various IT projects. One such project involved a migration effort to port functionality from one application platform to another new platform. The company and the vendor developed and agreed on a project timeline and associated budget. However, at the end of the allocated timeline, the vendor reported that the migration could not be completed without additional time and money.

The company was reasonably concerned about the success of the project and wanted more information as to why the vendor was unable to complete the project within the agreed-upon parameters. As a result, the company brought David Consulting Group on board to size and evaluate the work had been completed to-date, resulting in an estimation of how long that piece of work should have taken.

The objectives of the engagement were to:

  • Provide a detailed accounting of all features and functions that were included in the software being evaluated
  • Calculate the expected labor hours by activity, along with a probability report (risk analysis) for the selected releases

DCG’s initial estimate was significantly lower than what the vendor was billing for that same set of development work. With such a significant difference in the totals, it was clear that something was off. DCG investigated the issue with the vendor to explore what data could be missing from the estimate, including a review of the assumptions made in the estimate regarding:

  • Size of the job
  • Degree of complexity
  • Team’s ability to perform

In the end, the company and the vendor accepted the analysis and utilized the information internally to resolve any issues relevant to the project and as a result the company also decided to use another software vendor for any future software projects resulting in a significant cost saving.


This case study highlights a typical business problem wherein projects are not meeting agreed-upon parameters. In cases such as these, Function Point Analysis proves to be a useful tool in measuring and evaluating the software deliverables, providing a quantitative measure of the project being developed. The resulting function point count can also be used to track other metrics such as defects per function point, cost per function point and effort hours per function point. These metrics along with several others can be used to negotiate price points with current and future software development vendors to ensure that the company is receiving the best value for their IT investment.

The estimation process helps in keeping vendors accountable for the work they are producing by providing solid data on the realistic length of a project as well as the relative cost of the project. Quantitative estimates on project length allow companies to better manage their vendor relationships with increased oversight and an enhanced understanding of the expected outcome for their software deliverables.

Written by Default at 05:00

Top 5 Reasons Projects Fail

Reasons IT Projects Fail

IT projects fail all the time - too often, we'd say here at DCG, since most of the reasons projects fail are preventable. Unfortunately, many of our clients are plagued by the same issues, all of which lead to bottlenecks, delays, overspending, unhappy employees and unhappy customers.

However, successful software projects are possible! We can avoid these issues, and the best place to start is by examining exactly what those issues are. Download "The 5 Reasons Projects Fail" to find out the 5 most common issues our clients experience. Then read on to discover what you can do to prevent them.

Download: 5 Reasons Projects Fail

Written by Default at 05:00

ICEAA Professional Development & Training Workshop

Last week DCG's Tom Cagley, VP of Consulting, and David Lambert, Software Sizing and Estimation Specialist, attended the International Cost Estimating and Analysis Association's (ICEAA) annual Professional Development and Training Workshop in San Diego.

It was a great event, bringing together professionals from government, industry and academic cost communities to discuss one of our favorite topics here at DCG: Estimation.

The event program featured speakers, training and an exhibition hall, with the goal of furthering attendees' understanding and appreciation of using data-driven estimating and analysis techniques.

Tom and David both presented at the event - and both presentations are available for download:

  • Agile Estimation Using Functional Metrics: Learn how combining the discipline of functional metrics with the collaborative approaches found in Agile parametric estimation has proved to be an effective way to estimate in an Agile environment.
  • Put Some SNAP in Your Estimating Model: Learn how the sizing framework, the Software Non-Functional Assessment Process (SNAP), can be used to size non-functional software requirements, providing a more complete and accurate assessment of the size of a project.

Download the presentations here and contact Tom or David for more information or with any questions. More information about DCG's Estimation Solutions and Consulting Services are available here and here.

We enjoyed the conference (and were happy to see such an interest in estimation), and we hope to attend again in the future!

Written by Default at 05:00

Why are IT Project Estimates Like Electoral Polling?

Steve KitchingHere in the UK we’ve just had a general election, and as usual, the results differed from the conducted polls. For weeks, estimates of the number of seats and percentage of the votes put the results neck-and-neck for the two main parties. Now, the pundits and press are running around like headless chickens, and the expectations for the next few weeks have flown out of the window. Planned TV shows and editorials based on who would join with whom have now become confetti, as the Conservatives won an election that looked impossible for anyone to win.

The early exit poll predicted a win for the Conservative party. It was based on a blind sample at the polling stations and it seemed a little optimistic, but even that prediction (316 out of 650 seats) was exceeded in the final result of 331 seats. To be fair, the exit poll had the best and most up-to-date information and the margin of error was only 5%.

So, why is an IT project like an election? Like the polls, any estimate will be wrong; by definition, it’s an estimate, not reality. It’s impossible to consider everything that might happen on a project that could impact the real effort and duration, and the earlier you estimate, the less accurate the estimate will be because a lot of detail will be missing.

Like the polls, the estimate sets an expectation and people plan around it; the information is used to set the resources and schedules needed to deliver the project and to set commitments, both internally and with the client. The media made assumptions based on the early polls, and in IT project budgets, we also tend to put too much store in the early estimates, ignoring the margin of error. This is something we have to acknowledge and deal with as the project progresses and better information emerges.

The key is to use the best information available at the time to deliver the estimate and re-estimate as we know more. Reconcile multiple estimates and engage techniques such as parametric modelling and experienced-based estimating with historical data to deliver robust estimates and to plan with sufficient contingency and flexibility to deliver the project within the levels of expectation.

We know that any estimate will be wrong, but the error margin can be improved by repeating the exercise as new information is gathered. With perfect information you can get a perfect answer – in an election the perfect answer is when all the votes are counted, in an IT project, it’s at the point of delivery.

Steve Kitching
Software Sizing and Estimation Specialist

Written by Steve Kitching at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!