Comparison book review: "Software Estimation" by Steve McConnell and "Agile Estimating and Planning" by Mike Cohn

For this review, I am comparing two recently-published books concerning estimating activities on software development projects. Cohn’s book, as the title suggests, is firmly aimed at the agile development end of the market. McConnell’s book, while covering all sizes of project, will be more useful to practitioners running projects in the large software/systems engineering sector.

There are two interesting findings: one is that Cohn’s book contains much useful material that is otherwise scattered throughout the literature – and material that a casual reader would not expect to find in a book on agile development techniques. The other is that McConnell’s book encompasses the techniques in Cohn’s book and sets them alongside others for comparison.

McConnell’s books include “Rapid Development”, a title that is still the best book on software development techniques that we would now call “agile”, although the book predates the term by several years. “Software Estimation” expands and updates the material on estimating from the earlier book.

McConnell’s book starts with some simple but often mis-interpreted definitions of the difference between estimates and targets. The former is ideally a date-range whereby a piece of work may be finished; a target is a date commitment to meet this. The emphasis on having a date-range for an estimate has echoes of Demarco and Lister’s work.

He also provides useful definitions of large, medium and small projects. He defines large as having more than twenty-five technical staff, with project duration in excess of twelve months; small as having five or fewer staff and medium as those falling in between.

In addition, he categorises project type as either sequential or iterative in terms of whether most of the requirements are fixed early in project (sequential) or whether most are defined after some construction has started (iterative); those techniques defined as agile, such as XP, Scrum and DSDM, fall into the  iterative category, while those such as RUP and plan-driven fall into the sequential category.

McConnell goes on to describe various different estimating techniques and shows there applicability to the size and the type of project.

  • expert judgement – little more than guesses by subject-matter experts;
  • decomposition – breaking down functionality to small, estimable chunks;
  • analogy – getting estimates on a new project by comparing actual figures from a past project;
  • proxy – using other measurable items such as function points or story points as proxies for lines of code;
  • group – allowing a group of experts to estimate and negotiate a commonly-agreed figure;
  • tools – using software-based tools to generate estimates.

In addition, he describes how to use two or more methods in parallel in increase the confidence in the estimates.

McConnell chooses to base most of his book using lines of code (LOC) as a standard. This measure has fallen out of popularity, especially in agile estimating circles. The author makes a robust defence of this, making the points that:

  • it is a measure that it is common to all software projects;
  • there are associated historical effort figures on which to base estimates;
  • that different software languages will have different productivity factors that need to be accounted for – factors which the author lists in the book.

He advises starting with LOC if nothing else is available – other standards may be chosen as long as they are countable and effort-based historical records are available for which to base the estimates on.

Some interesting findings stand out:

  • for a 10% reduction from the nominal schedule, you need a 30% increase in staff numbers;
  • it is not possible under any circumstances to reduce schedule by more than 25% from the nominal;
  • as a rule of thumb, the minimum schedule time can be calculated by doubling the cube-root of the number of estimated staff-months.

McConnell also describes estimating using story points. This technique, popularised by highly-iterative agile methods such as XP, is when the team decompose the requirements into small elements and then use an arbitrary scale of estimates. For example a small requirement may be “one point”, whereas as larger one may be “five points.” Initially, converting the arbitrary value to an effort estimate is performed using historical figures by analogy, but as the project progresses, subsequent estimates are performed using historical results from the previous iterations.

Cohn’s book is directly applicable to those projects that McConnell describes as small – but the book contains much additional material that makes it worth reading for practitioners of all project sizes. For example, there is a complete chapter on the prioritisation of requirements by desirability using Kano analysis. This technique divides requirements into three groups:

  • Essentials – those requirements that are essential for the stakeholder to even consider using it;
  • Linears – those requirements that are linearly valuable, ie those where doubling an element of the requirement is perceived as being twice as desirable;
  • Delighters – those requirements that delight a stakeholder - usually only a small number being necessary.

The author describes techniques to draw up a questionnaire based on Kano analysis for potential customers to quantify which requirements they categorise into the three categories above. This will also business stakeholders (such as product managers) to prioritise requirements.

Cohn has a whole chapter on financial prioritisation – techniques that allow the quantitative financial measures be associated with requirements. The measures discussed are: cost (retained revenue, operational efficiencies and net cash flow), net present value, return on investment and discounted payback period. Armed with this information, business stakeholders are able to prioritise the requirements more easily. In addition, this sort of information adds credibility in the eyes of the CFO, who may otherwise remain unconvinced of the benefits of agile projects.

In addition, Cohn devotes part of the book to estimating buffer size  - something that is often missed in agile projects. He deals with both feature and time buffers and the best time to use each - or a combination of both.

Both books can be highly recommended. McConnell’s book summarises and updates all the techniques for software development estimation for all types of projects. However, it is especially useful for practitioners on larger projects, as other literature in this area has not kept up-to-date with recent technologies and techniques.

Cohn’s book, while aimed at agile practitioners, becomes a “best buy” for all with its in-depth, readable treatment of topics that are rarely seen in a software development book.

Book details: Agile Estimating and Planning | Software Estimation

Success Stories

"Agilier's experience in managing business processes made them an ideal candidate to manage functional integration thereby reducing a significant risk to the business. This involved them working with the workstream leads and developing a high-level integrated businesses process against which we planned our programme."

Chris Davies
Programme Manager, EADS Defence and Communications Systems


"I was extremely happy with the professional and complete way that Agilier performed their work and would not hesitate to use their services again."

Mike Haynes
Senior Project Manager, Cogent Defence and Security Networks

Book Reviews


Our latest writings, or thought-pieces, appear here.

Take a look at our free, time-saving templates in our new section.

Keep in touch with the latest ideas to help your organisation deliver. Click here for more.

RSS Feed