Estimation of Requirements and Tasks

A requirement must be formulated in a way that the Team is able to estimate the effort. The Product Owner formulates his functional requirements in the form of Items, the Team specifies these by assigning the Item activities to so-called “Tasks”. The effort can be estimated by the Team, based either on the level of the Items or the level of the Tasks.

There are different ways to estimate documented requirements. Two commonly used variants exist in Scrum.

Planning Poker

The first option is the so-called “Planning Poker”. Here, effort categories are defined, which are then assigned to the Items or Tasks. The effort categories are first described technically, for example “very little effort”, “little effort”, “very neutral effort”, “high effort”, “very high effort”, “extremely high effort”. These categories are then assigned to numbers, for example, the Fibonacci Sequence, as here the distances between the numbers increase.

The effort categories are broken down as follows:

Scrum Breakdown of effort categories

Table 4: Breakdown of effort categories

The Team meets for Planning Poker and rates each Item with a number from the Fibonacci Sequence. For example, the first team member rates an item with 3; the second team member with 2 and the third with 8. The assessment will therefore vary by a few points. This example shows that the Team apparently has difficulty reaching a common effort category – there is a need for clarification here. The Team will now describe this Item or Task in further detail so that the estimate is better possible.

The Team then adopts a certain number of Items per Sprint. By the allocation of efforts by category, the Team will find out from Sprint to Sprint how many Items can be implemented per Sprint according to the above categories.

Actual days and the Beta-Distribution

The second option is the estimation and planning of actual days. It is first recorded as to how many hours per day are available for the development in real terms, e.g. five out of eight working hours per day, which are then scheduled by the Team. Each Item is added to its Tasks and estimated by the team members. Different estimation methods are used for this, e.g. PERT (Program Evaluation and Review Technique), from traditional project management.

The following three values are relevant: Effort in Best Case, effort in Average Case and effort in Worst Case. By using this three-point estimate, the task automatically includes the subjective estimations of the estimator. Tasks can also be estimated simultaneously by a number of people or estimated one after the other. The calculation gives the average duration.

Example calculation:

Task 1 has in the Best Case four hours, six hours in the Average Case and 18 hours in the Worst Case. This estimate gives direct information that some uncertainties are concealed here because the Worst Case is three times higher than the assumed Normal Case.

The following formula results from the beta-distribution:

PERT formula

Diagram 23: PERT formula

In this case it results in 7.66 hours. Other additional methods, such as the calculation of the standard deviation, can give additional information on the uncertainty of the estimate.

In this procedure, the Team either carries out a specification of the tasks because there is too much uncertainty in the estimate, or it would schedule the 7.66 hours. As a real day has just five hours, about 1.5 days of development would therefore be scheduled here.

A buffer in the planning can be calculated in a way that more sigma (standard deviation) of the three-point estimates are taken into account and added to the estimated effort. This is revealed with a statistical probability in which the planned efforts occur. Three sigma corresponds to a statistical accuracy of 99.7%.