ALM: User Guide

To understand how many requirements, and which ones, fit in a release or iteration, you need to estimate them. You can estimate the effort or the complexity of requirements. The units (hours, Story Points) are configured in the project methodology.

Teams most often use one of the simple techniques: estimation in ideal hours, or estimation of complexity in abstract units ("parrots"). An hour is called ideal because work constantly loses time to helping a colleague, tea, discussion, and so on. Each person therefore usually has 5–6 ideal hours in a day, not 8. This estimate is suitable when one person will work on the task, previous experience is used, or the requirements are detailed enough. In other cases such an estimate is very inaccurate, so an alternative is used: estimation in abstract units, for example sizes or Story Points (SP for short). These are abstract values that describe the complexity of a task (user story).

The simplest complexity estimate is T-shirt sizes: X, L, M, S. This estimate is fast and rough, but it shows what the team can do and ranks tasks by complexity, for example for prioritization: do the simple and important ones first, then the complex and important ones, and so on.

Story Points give a more accurate estimate. Because they are abstract by themselves, estimation uses a scale that reflects increasing task complexity. The scale was built from research showing that we tell something complex from something even more complex when the estimates differ by about 160%–170%. SP estimation therefore uses a Fibonacci sequence (1, 2, 3, 5, 8, ...) or powers of two (1, 2, 4, 8, 16, ...). Which one should you choose?

The higher the task complexity, the higher the uncertainty and the larger the error, so only the first few points of the scale can be used effectively, for example up to 40. Stories estimated above that value are better split into smaller stories, and more detail should be found out. The powers-of-two scale is coarser and therefore simpler to use, but obviously less accurate. Stay with powers of two if the team is small, the iteration has few stories, and the requirements are not very uncertain. In other cases it is better to use Fibonacci and run iteration planning in the "Planning poker".

If a requirement's complexity can be estimated quickly, do it systematically by reviewing the requirements backlog regularly and entering the complexity estimate directly in the backlog:

You can configure estimation scales: adjust the existing ones or create your own. Go to Administration, Settings, Reference lists. Open the "Estimation scales" list and edit the system scales or create new ones. The "Hour equivalent" field maps a complexity estimate to the time needed to implement a story or issue. The hour equivalent of an estimate is used to plan the implementation dates of a story from the estimate given.

If estimation takes longer, or several people from the development process must be involved, you can add a special requirements lifecycle stage, for example "Clarification" or "Estimation". Participants can meet, discuss the requirement, and save the resulting estimate on the requirement or enhancement card. If they cannot meet, they can record their estimates on the tasks that break the requirement down:

Once a set of requirements is estimated, it is easy to see whether those requirements fit in the next release or iteration. A release and an iteration have a duration. Given the team velocity — the amount of work done per day — you can determine the capacity of the release or iteration. Use these indicators when planning the contents of a release or iteration:

A more laborious way to prioritize is the WSJF method. The priority of a requirement (story) is calculated from a formula that depends on criteria such as:

• Effort estimate — the amount of effort (or time) needed to implement the requirement;
• User value — the benefit the user gets when the requirement is implemented;
• Time criticality — how time-critical the requirement is; the higher the score, the sooner the requirement should be implemented;
• Risk reduction — how far implementing the requirement removes or reduces user risks (data loss, inability to do the work, extra effort, reputational risks, and so on).

Use the corresponding modules, for example

The system calculates the WSJF Priority, which you can sort rows by. Requirements with the greatest value for the customer and the least effort are placed at the top. The units of the coefficients follow the effort-estimation settings in the project Methodology.

You can change the formula by adding your own coefficients or by introducing new criteria.