Relative Estimation of User Stories Using the Ordering Method

Software project estimation has always been challenging because, unlike civil engineering, software development lacks mature reference tables, making it necessary to estimate investment effort. This article focuses on user story estimation in agile development, distinguishing between absolute (time‑based) and relative (size‑based) estimation.

Common issues in relative estimation include difficulty finding a suitable baseline story, developers concentrating on point values rather than relative size, and the process often consuming an entire afternoon or more.

Sorting Estimation Method

2.1 Purpose: Create a release plan using a set of story cards. 2.2 Scenario: Large projects (1‑3 months) with a well‑defined story list following the INVEST principle, where each story is understood by at least two developers. 2.3 Assumptions: Story size is objective and independent of the individual developer, developers understand the work, and the sample size is large enough to avoid bias.

2.4 Estimation Process:

Write all user stories on cards and distribute them evenly among developers.

Pick any card (A) and place it on the wall as the initial reference.

Each developer takes a card (B) and compares it with the cards already on the wall: If B is about the same size as A, place it directly below A (see Image 1). If B is larger than A, place it to the right of A (see Image 2). If B is smaller than A, place it to the left of A.

Continue with the next card (C), comparing it with the existing wall: If C is smaller than all cards, put it on the far left; if larger than all, put it on the far right. If C fits between two cards (e.g., between A and B), place it between them (see Image 3).

After all cards are placed, the team reviews the wall to ensure each card’s position feels appropriate (Image 4).

If any position is disputed, discuss and adjust until consensus is reached.

Assign numeric columns (e.g., 1, 2, 3, 5, 8, 13) to the ordered groups; the numbers represent relative size, not exact time (Image 5).

For columns without a numeric label, place them into the nearest appropriate column based on size (Image 6).

Finally, multiply the number of stories in each column by the column’s numeric value and sum the results to obtain the overall project size.

Notes

Ensure story size differences are not extreme; otherwise, split or merge stories to satisfy the INVEST “S” (Small) principle.

If the distribution of cards across columns is not roughly normal (many at the extremes, few in the middle), story granularity may need adjustment.

When multiple related stories of similar size exist, consider placing the smallest in the current column and the others in a slightly smaller column after one is completed.

During discussion, compare cards rather than referring only to column numbers, as the numbers are relative.

Capture any newly discovered issues or information during the session; unresolved questions should be answered on the spot by business stakeholders.

For teams new to relative estimation, an experienced facilitator should guide the process and validate the resulting order.

Case Study

The author applied this method to a team of 40+ stories, completing the estimation and release plan in about 1.5 hours. The team used a Fibonacci sequence (1, 2, 3, 5, 8, 13) for column labels; larger stories (8 and 13) were later split into smaller ones fitting the 1‑2‑3‑5 pattern. In one instance, the “1” column remained empty, illustrating that a baseline of 1 is not always required.

Summary

For teams new to agile, this relative sizing and planning approach can be hard to accept, especially for those accustomed to WBS‑based planning, because the meaning of “1” can be ambiguous. Successful use depends on thorough story discussion, adherence to the INVEST principles, and the assumption that testing is not the delivery bottleneck.

The author emphasizes that the method estimates only development effort; testing effort is assumed to be negligible in the sizing calculation.

Promotional Note

Instructor Qiao Liang is offering a limited‑time discount on the video course “Continuous Deployment Training Camp (Python Edition)”, which covers building, testing, and deploying pipelines, monitoring deployments, gradual feature rollout, and database schema changes.