Estimation: What Should be Considered in Practice?

Tips & Tricks

How Big Should the Work Packages be?

How finely should the work packages be subdivided when creating a WBS for project estimation? A single work package should not exceed 40 hours, since efforts up to this size are tangible and imaginable for humans.

In individual cases, it can also be a maximum of 80 hours - however, if there are many such or even larger packages, it is advisable to divide them up further. Otherwise, if the units are too large, we tend to forget individual sub-steps.

How to Estimate Debugging Effort?

There are packages in the WBS that are not so easy to estimate, for example debugging during integration and testing. How many errors will probably occur there?

Historical data from previous projects provide very good clues here. In a project of similar complexity, perhaps 5% of the effort was spent on testing and debugging, so it is reasonable to assume that it will be similar for the project being estimated.

These percentages can also be used directly for coarse estimation. For example, we know that the System Design phase is pretty much 10% of the project effort. When this phase is completed, we can estimate the whole project quite well.

Planning

What Good is an Estimate with such Large Uncertainty?

What is the use of estimating a work package with 8 to 40 hours? What should I do as a decision maker with such a range?

Here we are helped by an important statement of the probability calculus, which ensures that the sum of the estimates of a sufficiently large number of work packages leads to a smaller range of the total estimate. For example, 10 work packages with estimates of 20 to 60 hours can lead to a total estimate of 180 to 350 hours, which means that the range is reduced from 200% to 100% even with only a few packages.

Practically, this means that the estimators can or even must fully incorporate their uncertainty about the individual work package into the estimate. The result of the estimation will be sufficiently accurate for a decision or initial planning.

The Effort is One Year, so the Project is Done in One Year!

When planning the milestones based on the effort estimate and the available resources, it is important to assume a reasonable workload. With vacations and other absences, as well as internal work, training, administration, etc., it is virtually impossible to use every hour of work productively on the project.

Estimation Effort

Why such a fuss, in our company the manager does it before the lunch break!

The heroic approach, according to which the best employee should provide an estimate, is widespread. But how good is your hero/ heroine?

Perhaps it helps to interview several such heroes? But what happens when everyone else follows the lead hero? What to do against Groupthink? The problem has been solved for some time: with the Delphi method, also known as Planning Poker.

How do you limit the estimation effort?

The estimates themselves should always be budgeted or limited in time. Otherwise, once the engineers are in the discussion, the effort for an estimate quickly becomes immeasurable. Time timers or egg timers, for example, are suitable for time limitation.

When budgeting estimates (the estimation of the estimation effort), you should use realistic values, because for really large projects the estimation effort is also correspondingly high. For a large project, Solcept invests about 1% of the project effort in estimation.

The investment is worthwhile because fewer estimation errors allow more accurate, efficient planning and correction measures can be initiated at an early stage. For example, a first product with a smaller feature set can be brought to market early early, if it is seen that the development of the entire product range is taking too long.

In addition, the effort for project management is reduced, because the project estimation provides all information for the first planning step with the WBS and the risk table. For example, by transferring the Work Breakdown Structure with all information into a Backlog, which can even be done automatically.

Historical Data

How to verify the estimate?

Probably the best way to perform verification is to use historical data. What was the effort for the last, similarly complex project? This should match the estimated result at least in magnitude.

And how do you Get such Historical Data?

To be able to use historical data for estimates, you first have to have it. This means that for each project there must be a controlling of the effort with sufficient granularity. For example, you can record the effort per project phase.

It is important that the structure of the recording coincides with the structure of the estimation, for example the project life cycle, otherwise the comparison becomes difficult. This way, over time, a database is created that supports the estimates.

At Solcept, we have set up a kind of "round trip" in that the estimate for a project just generates the tickets in our ticket system (Jira) for the project. The structure of the WBS along project phases is mapped into these tickets. New tickets are immediately assigned to project phases according to the project lifecycle.

All employee time tracking then takes place on the tickets. After the end of the project, we can evaluate the time recording data over the project lifecycle with a business intelligence solution and use it for new estimates.

Planning Poker Usage

How to Make a Two-Point Estimation?

Since the cards have a more or less logarithmic scale (0, 1, 2, 4, 8, 20, 40, 80), a two-point estimate for the maximum effort, i.e. the worst case, actually always ends up at twice the normal effort. This can be avoided by having the estimators report the difference from the normal case, the "spread" of the estimate, that is, for a normal case of 20 hours, the estimators report the difference as, say, 8 hours, resulting in a maximum effort of 28 hours.

And I have to Estimate the Price As Well!

The methods given can be modified to estimate quantities such as production prices, power consumption, etc. Especially Planning Poker can be used very well. The numbers are then interpreted, for example, as monetary value or power (4 as 40 EUR or 8 as 8 mW). You can be quite creative here.

What do Risks do in Effort Estimation?

"If a project has no risks, don't do it!" Tom DeMarco, Timothy Lister

Here, not only the inherent uncertainties of an estimate are meant, but above all the risks that could occur on top of it. These are always false assumptions that do not occur and trigger additional expenses. Examples are component discontinuations, missing or faulty inputs, changing standards, non-functioning technologies and, above all, changes in requirements.

Without consciously managing these risks, project management makes no sense [T. DeMarco, T. Lister: «Waltzing with Bears: Managing Risk on Software Projects», 2003 ISBN 0-9326633-60-9].

Since for some risks it is easier to formulate them as assumptions, and others as residual risks (i.e., risks beyond the estimated fuzziness), we use two columns in each estimation table, one for assumptions, one for risks. These can be filled in either when the structure is created (WBS/ FBS) or then as a result of discussions during Planning Poker. Besides the estimated effort, this is the most important result from the discussions during Planning Poker.

In order to estimate the total risk, all assumptions and remaining risks are now collected in a risk table. Assumptions are reformulated into risks: The assumption "the purchased USB software works" becomes the risk "the purchased USB software does not work". All risks are then estimated according risk management.

Since we also want to get better, please enter your comments below , ideas, suggestions and questions. I will then incorporate them into a next version.

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!

Would you like to benefit from our knowledge? Visit our contact page!