Estimation

Estimation

The Impossible Region, Revisited

In software estimation, some discovered relationships turn out to be true primary principals of software development.

Way back in 1978, Larry Putnam, Sr. discovered that the relationship between project duration and project effort was exponential.1  His equation equated to:

Duration in months = 2.15 times the cube root of effort in manmonths

In his 1981 book, Barry Boehm described the nominal relationship in COCOMO2 as:

Duration in months = 2.5 times the cube root of effort in manmonths

Very similar results.  Is that something specific to the way projects were managed way back then?  Or, is this a true fundamental law of software project management?

Sometimes, it is fun and also informative to revisit pioneering work to see how things have (or have not!) changed over the decades since.  I have used updated benchmarking data to check this staffing relationship and found it to be surprisingly persistent. 

I took project Main Build (Design through Test) effort and Main Build duration from the QSM database, for projects that have competed in the 21st century.

The following graph has duration in months on y axis, and effort in personmonths on x axis.

The exponential regression shows that the “nominal” duration of these projects = 2.0 x cubed root of effort.  

Software Project Impossible Regision

Blog Post Categories 
Estimation

Do We Need to Estimate Agile Projects?

We speak to a number of scrum masters, project managers, and CIOs each month. QSM does research on software development projects - all types, including agile and waterfall. We work with a huge database of completed software projects, updated with new industry data on a regular basis. We provide predictive analytics and we study cost, schedule, risk, quality, size, resource demand management, business intelligence, and vendor management.

Within the last couple of years, we have been hearing some agile managers say that there is no need to estimate agile projects. They say that they are managing in smaller increments or sprints and that they already know how much velocity can be achieved. They also say they are constantly “grooming the backlog” so there is no need for a formal estimation model to forecast the amount of work that needs to be done. They are managing at the sprint and task level so they feel like they have everything under control.

The bottom line is that agile projects still need to be estimated to see the big picture: the release estimate. It's essential to know the release cost and effort before the project plan is handed off to the scrum master and before committing to the customer. The negative feedback we hear regarding estimation is somewhat ironic because agile processes actually lend themselves very well to formal estimation since they promote the use of size measures like user stories, story points, and epics. Having good size information is a big part of estimating successfully.

Blog Post Categories 
Agile Estimation

Should Task Planning Occur Before Software Estimation?

I work for QSM, a leading software project estimation and demand management company. We focus on top-down estimation, meaning we figure out the total project duration and effort before any detailed planning occurs. We use SLIM-Estimate also known as the Putnam Model. Larry Putnam Sr. introduced SLIM in 1978. It is one of the leading software estimation tools in the world, validated with over 35 years of industry leading research and updated regularly with the latest technologies. 

Many people call us for help with team size software project estimation, they want to see how many people it’s going to take to deliver a specified amount of functionality within a certain duration and budget. At the time they call us they are often using task level planning tools to try to figure this out. 

The problem is that it’s tough to allocate people and the number of hours they will work when they haven’t figured out the specific requirements of each task and when they haven’t estimated the total duration and effort for the overall system. A manager could spend days creating a task level plan that doesn’t add up to the overall project duration and budget that is needed to deliver the functional requirements. When it doesn’t add up then re-planning has to take place costing more time and money. This is why QSM recommends estimating the big picture first, the scope level. 

Blog Post Categories 
Estimation Process Improvement Sizing

New Book - Understanding Software Estimation, Negotiation, and Demand Management: An Executive Primer

Understanding Software Estimation, Negotiation, and Enterprise Demand Management: An Executive Primer

QSM is pleased to announce the release of a new book, Understanding Software Estimation, Negotiation, and Demand Management: An Executive Primer. Historically, only 20% of software projects are completed successfully and with software becoming critical to nearly every company and industry, having such a high rate of failure is simply unacceptable anymore. It is for this reason that QSM has compiled this collection of articles that will aid anyone from project managers to CIOs in implementing software estimation, negotiation and demand management methods efficiently to reduce costs.

Larry Putnam, Sr., founder of QSM and a pioneer and top problem solver in the software estimation and measurement field, provides the foreword to the book, which is co-authored by his son and granddaughter, Doug Putnam and Taylor Putnam-Majarian. Combined, the authors bring more than 40 years of experience in software measurement to a range of topics, including:

New Article: Full-Circle Estimating

 Full-Circle Estimating

While creating estimates is a fundamental step toward improving productivity on software development projects, it is not enough. In "Full-Circle Estimating," recently published on Projects at Work, Doug Putnam and Taylor Putnam-Majarian present a full-circle model that organizations can apply to track actual performance against estimates, reforecast when significant changes occur, and then continually refine the process through post-mortem assessment.

Doug Putnam is co-CEO for Quantitative Software Management (QSM). He has 35 years of experience in the software measurement field and has been instrumental in the development of the SLIM Suite of software estimation and measurement tools. C. Taylor Putnam-Majarian is a consulting analyst at QSM with over seven years of specialized data analysis, testing and research experience. In addition to providing consulting support in software estimation and benchmarking engagements to clients from both the commercial and government sectors, Taylor has authored numerous publications about Agile development, software estimation and process improvement.

Read the full article!

Blog Post Categories 
Estimation Articles

Software Project Size and Road Construction

Software Project Size and Road ConstructionI have been a software project estimator for 20 years.  Like many people who have worked a long time in their profession, I find myself applying my work experience to other events in my life.  So, when a family member tells me that he or she will be back from a trip into town at 3:30, I look at their past performance (project history) and what they propose to do (project plan) and add an hour.  Usually, I am closer to the mark than they are.

Blog Post Categories 
Software Sizing Estimation

IEEE Presentation: Key Components of a Successful Estimation Process

Key Components of a Successful Estimation Process

Focused on planning for software projects, this IEEE presentation by Keith Ciocco explains some of the key components of a successful estimation process. This is a summary level view focusing on the importance of leveraging historical data, sizing, and measuring productivity when estimating at the organizational and project level. This presentation includes a demonstration of the SLIM Suite of tools to show how we can automate and streamline the estimation process.

Watch the replay of this presentation!

Blog Post Categories 
Webinars Estimation

Trend Based Solutions Generate Reasonable Estimates Fast

Beginning with the release of SLIM-Suite v8.1, two new SLIM-Estimate solution methods were added to let you see what a “typical” project would look like: that is, the resources it would require, based upon historical projects from either the QSM database or your own.  The two methods are:

  • Solve from Trends Wizard
  • Trend Based Solution

SLIM-Estimate provides several different ways to solve the software production equation and produce an estimate.  The solution method you select depends upon the information you have available.  The traditional methods, known as Quick Estimate Wizard and Detailed Method, take inputs of Size and Productivity (PI), and calculate Effort and Time.  The Solve for Size Wizard, perfect for time-boxed estimates, takes inputs of Time, Effort, and PI, and determines the amount of functionality that combination of resources can produce.

The trend solutions require only one input – Size.  Using the specified Primary Trend Group, Time and Effort are read from the average trend line and productivity (PI) is calculated.  These methods extend the capabilities of producing a defensible project estimates very early in the life cycle.  You can determine the feasibility of project goals, assess risk, and manage stakeholder expectations even if all you can estimate is a relative application size, expressed as a “T-shirt” or bin size, as shown in the figure below.

Software T-Shirt Sizing

Blog Post Categories 
Estimation

Staffing a Successful Estimation Center of Excellence

When an organization wants to proactively manage their software activities from inception through development and sustainment, an enterprise software estimation or acquisition Center of Excellence (COE) is a great solution.  A significant portion of our professional services business at QSM is helping companies design and stand up enterprise COE operations. 

There are three main components to a successful COE implementation.  They are:

  1. Estimation Center of ExcellencePeople – Finding people with the right characteristics and developing their skills;
  2. Business Processes – developing the right business processes to support decision making; and
  3. Tools – Acquiring and configuring analytical tools to support the business processes.

Our clients often ask us to identify the best characteristics and skills for a person that they plan to staff into a COE.  We went back and looked at our most successful implementations, and here is what we found.

Ideal Enterprise COE Skill Set:

Blog Post Categories 
Consulting Estimation