ALM User's Guide

You must estimate requirements prior to include them into the release or iteration. You can estimate workloads or complexity of requirements. You can set up the corresponding units of measurement (Hours, Story Points) in the project methodology.

Most often teams use one of the simple techniques: estimation in ideal hours or complexity estimation in abstract units (the so-called parrots). An hour is called the ideal unit because there are constant breaks during the work time: helping a colleague, tea drinking, discussions, etc. So each employee usually have 5-6 ideal hours for working daily, not 8. Such estimation is suitable if one employee works on this task, previous experience is used, or the requirements are detailed enough. In other cases such estimation will be very inaccurate, therefore alternative method is used - estimation in abstract units, e.g, in sizes or Story Points (SP). These abstract units characterize the complexity of task (user story).

Sizes of T-shirts represent the simplest example of complexity estimation: X, L, M, and S. Such estimation is fast and rough, however it allows to demonstrate team possibilities and rank tasks by their complexity, e.g, for prioritization purposes - first we'll do simple and important tasks, then continue with complex and important tasks, and so on.

Story Points allow to get a more accurate estimation. Since these units are abstract by nature, estimation is carried out using a scale that reflects growing task complexity. In order to construct such scale we used the researches showing that we distinguish a complex issue from the more complex issue only when their estimation differs from each other on approx. 160% - 170%. Therefore, to estimate complexity in SPs we use Fibonacci sequence (1, 2, 3, 5, 8, ...) or degrees of the two (1, 2, 4, 8, 16, ...) to construct a scale. Which one should we choose?

The higher the task complexity is, the higher is the uncertainty and the more is the error. Therefore, it's efficient to use only several initial elements of the scale, e.g., up to 40. All stories having an estimation that exceeds this value must be decomposed into smaller stories to figure out more details. The "Degree of the two" scale is more rough and simple in usage, however it's less accurate. You should use this scale ("Degree of the two") if your team is small, the iteration contains few stories, and the uncertainty level in the requirements is not high. In other cases, it's better to use Fibonacci numbers and organize iteration planning in the form of "Planning poker".

If you can estimate complexity of the requirement quickly, you can perform it systematically by periodical browsing of the requirement backlog and storing estimation of the complexity directly into the backlog:

If the estimation process takes more time, or you must involve several participants of development team for it, you can allocate a special stage of requirement lifecycle, e.g., “Clarification" or "Estimation". Participants can come together, discuss the requirement, and store the resulting estimation into the requirement or enhancement card. If it's impossible to gather team members, they can store their estimations in the corresponding tasks after decomposition of the requirement:

After estimation of the requirement suite it's easy to determine if these requirements can be included into the next release or iteration. Each release and iteration has its duration. Taking into the account velocity of the project team (amount of work items to be performed daily), you can determine the capacity of release or iteration. Use the following indicators when planning the content of release or iteration:

WSJF prioritization method consumes more resources. Priority of a requirement (story) is calculated based on the formula that depends on the following parameters:

• Estimation of workloads - amount of workloads (or time) required for the requirement implementation;
• User value - benefit that the users get after the requirement implementation;
• Time criticality - shows time criticality of this requirement. The higher the estimation is, the sooner must be implemented the requirement;
• Risk mitigation - degree in which implementation of this requirement eliminates or mitigates user risks (data loss, inability to perform work, excess workloads, reputation risks, etc.).

Use the corresponding modules, e.g.,

System calculates WSJF priority value, by which you can then sort rows. Requirements having maximum user value and minimum workloads are placed on the topmost. Units for coefficient measurement correspond to settings of workloads estimation in the project methodology.

You can modify calculation of the formula by adding your own coefficients or introducing new parameters.