Relative Sizing

Relative Sizing is a core practice in Agile and Lean methodologies for estimating the effort required to complete a piece of work. Unlike traditional estimation methods that attempt to predict work in absolute units of time (e.g., hours, days), relative sizing focuses on comparing the size of one work item to another. The fundamental idea is that it's easier and often more accurate for humans to compare the size of two objects than to assign an absolute measure to each individually. For instance, it's simpler to say "this task is twice as big as that one" than to precisely state "this task will take 16 hours, and that one will take 8 hours."

The practice emerged from the recognition that software development is inherently complex and uncertain. Early Agile practitioners, influenced by Lean principles, sought ways to embrace this uncertainty rather than fight it with overly precise, yet often inaccurate, time-based estimates. The concept gained significant traction with the rise of Scrum and Extreme Programming, where practices like Story Points and Planning Poker became popular methods for implementing relative sizing.

The primary purpose of relative sizing is to facilitate effective planning and prioritization without getting bogged down in false precision. When a team estimates items relatively, they are considering various factors such as:

• Complexity: How intricate is the problem to solve?
• Effort: How much work is involved in coding, testing, and deployment?
• Risk: What are the unknowns or potential obstacles?
• Uncertainty: How much is still unclear about the requirements or technical approach?

By discussing these factors collectively, the team develops a shared understanding of the work, which is often more valuable than the estimate itself. This collaborative discussion helps uncover hidden assumptions, identify dependencies, and clarify requirements, leading to better-informed decisions.

Relative sizing is important because it:

• Improves Accuracy: While not perfect, relative estimates tend to be more accurate over time than absolute time estimates, especially for complex, uncertain work.
• Fosters Collaboration: The estimation process becomes a team activity, promoting discussion and shared understanding.
• Reduces Pressure: It shifts the focus from individual time commitments to collective effort, reducing the pressure on developers to meet arbitrary deadlines.
• Enables Better Forecasting: When combined with a team's historical average throughput (Velocity), relative sizes allow for more reliable forecasting of future delivery.
• Supports Prioritization: Product Owners can use relative sizes, alongside business value, to make informed decisions about what to build next.

Within the wider knowledge graph, Relative Sizing is a foundational element of Agile Planning & Estimation. It directly relates to concepts like Story Points, which are the most common unit used, and estimation techniques such as Planning Poker and Affinity Estimation. It feeds into Capacity Planning, Iteration Planning (Sprint Planning), and Release Planning by providing the input needed to determine how much work a team can realistically commit to. It also plays a crucial role in Forecasting and understanding a team's Velocity, which measures the amount of relative size completed over a period.

The process of relative sizing typically involves a collaborative session where the development team, often facilitated by a Scrum Master, estimates a set of work items. While specific techniques vary, the underlying workflow follows a common pattern:

1. Establish a Baseline (Reference Story)

The first step is to identify a "reference story" – a well-understood, recently completed work item of small to medium size. This story serves as the anchor against which all other stories will be compared. The team assigns a specific relative size to this reference story (e.g., 3 Story Points or "Medium" in T-Shirt Sizing). It's crucial that the team has a shared understanding of what this reference story entailed in terms of complexity, effort, and uncertainty.

2. Select a Sizing Scale

Teams typically use a non-linear scale for relative sizing to reflect the increasing uncertainty as items get larger. The most common scales are:

• Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21... (or a modified version like 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100). This sequence naturally expresses that the difference between a 13 and a 21 is perceived as larger than the difference between a 1 and a 2.
• T-Shirt Sizing: XS, S, M, L, XL, XXL. This is often used for higher-level items like Epics or Features, or for initial, rough estimates.
• Linear Scale: Less common for detailed sizing, but sometimes used for very small, predictable tasks.

3. Compare and Estimate

For each new work item to be estimated:

1. The Product Owner or a team member presents the work item, explaining its purpose, requirements, and acceptance criteria.
2. The team discusses the item, asking clarifying questions to ensure a shared understanding.
3. Team members individually consider the item's complexity, effort, risk, and uncertainty relative to the established reference story and other previously sized items.
4. Using the chosen sizing scale (e.g., Planning Poker cards for Story Points), each team member simultaneously reveals their estimate.
5. If there are significant discrepancies in the estimates, the team discusses the reasons behind the differences. Those with the highest and lowest estimates explain their rationale. This discussion is vital for uncovering different interpretations, hidden complexities, or overlooked details.
6. The team repeats the estimation process until a consensus or an acceptable level of agreement is reached. The goal is not necessarily a unanimous vote, but a shared understanding and commitment to the estimate.

4. Refine and Recalibrate

Relative sizing is an iterative process. As the team gains more experience and completes more work, their understanding of their own capacity and the nature of their work evolves. It's good practice to periodically review and recalibrate the reference story and the team's understanding of what each size represents. This ensures that estimates remain consistent and meaningful over time.

The core principle is that the team doing the work is best positioned to estimate it. This distributed knowledge and collective intelligence lead to more robust estimates than those imposed by a single individual or manager.

Benefits

• Enhanced Team Collaboration and Shared Understanding: The discussion during sizing forces the team to align on requirements, technical approaches, and potential challenges, leading to a deeper collective understanding of the work.
• Improved Predictability: While individual estimates may vary, a team's average velocity (sum of completed relative sizes) tends to stabilize over time, allowing for more reliable Forecasting and Capacity Planning.
• Focus on Value, Not Time: By abstracting away from hours or days, relative sizing encourages Product Owners and teams to focus on the business value delivered rather than getting fixated on precise time commitments.
• Adaptability to Change: Relative estimates are more resilient to changes in team composition or individual productivity, as the relative scale remains consistent even if the absolute time taken by the team changes.
• Reduced Pressure and Stress: It removes the pressure of committing to exact dates for complex work, allowing teams to focus on delivering quality increments.
• Better Handling of Uncertainty: The non-linear scales (like Fibonacci) naturally account for the increased uncertainty in larger tasks, making estimates more realistic.

Limitations

• Initial Learning Curve: New teams may struggle to grasp the concept of relative sizing and detach from time-based thinking.
• Requires a Stable Reference: The effectiveness hinges on having a well-understood and stable reference story. If the reference shifts, all other estimates can become inconsistent.
• Not a Substitute for Detailed Design: Relative sizing provides a high-level estimate; it doesn't replace the need for detailed technical analysis and design for complex items.
• Misinterpretation as Absolute Time: Stakeholders (and sometimes even team members) may try to convert Story Points back into hours or days, undermining the purpose of relative sizing.
• Difficulty with Cross-Team Comparisons: Story Points are team-specific. Comparing Story Points between different teams is generally misleading due to varying definitions of "size" and different velocities.

Common Mistakes

• Converting Story Points to Hours: This is the most common and detrimental mistake. Story Points are not a proxy for time; they represent relative effort, complexity, and uncertainty.
• Estimating Individuals, Not the Team: Relative sizing should be a collective team effort, leveraging diverse perspectives. Individual estimates can lead to anchoring bias or missed insights.
• Not Having a Clear Reference Story: Without a well-understood baseline, estimates become arbitrary and inconsistent.
• Ignoring the "Done" Definition: Lack of a clear Definition of Done can lead to inconsistent sizing, as teams might estimate different scopes of work for similar items.
• Allowing External Pressure to Influence Estimates: Estimates should reflect the team's honest assessment, not external demands for faster delivery.
• Over-analyzing Small Differences: Spending too much time debating the difference between a 3 and a 5 when the item is relatively small can be unproductive. Focus on significant discrepancies.
• Not Re-calibrating: As a team matures and its understanding of its work evolves, the meaning of a Story Point might subtly change. Periodically reviewing and re-calibrating the reference story and scale is important.

Real-world Examples

Consider an e-commerce development team using Story Points for relative sizing:

• Reference Story (3 Story Points): "As a user, I want to log in with my email and password." (Relatively straightforward, known technology).
• New Story 1: "As a user, I want to reset my password." The team discusses it and agrees it's slightly more complex than login due to email integration and security considerations, but still manageable. They size it as 5 Story Points.
• New Story 2: "As a user, I want to integrate with a new third-party payment gateway (e.g., Stripe)." The team recognizes this involves external APIs, error handling, security compliance, and potential unknowns. They agree it's significantly larger and more complex than the login or password reset. They size it as 13 Story Points.
• New Story 3: "As an admin, I want to view a list of all registered users." This is simpler than the login, mostly a database query and UI display. They size it as 2 Story Points.

Through this process, the team gains a shared understanding of the relative effort and complexity, which then informs their Sprint Planning and Product Backlog Prioritization.

Best Practices

• Involve the Whole Team: All members of the development team should participate in sizing to leverage collective knowledge and foster shared ownership.
• Establish a Clear Reference Story: Ensure everyone understands what a "1" or "3" (or "S" or "M") represents by anchoring it to a concrete, recently completed task.
• Focus on Complexity, Effort, Risk, and Uncertainty: Remind the team to consider all these dimensions, not just perceived time.
• Use a Non-Linear Scale: Scales like Fibonacci better reflect the increasing uncertainty of larger tasks.
• Embrace Discussion and Disagreement: Discrepancies in estimates are opportunities for learning and clarifying requirements. Encourage healthy debate.
• Avoid Anchoring Bias: Don't let the first estimate mentioned unduly influence subsequent estimates. Techniques like Planning Poker help mitigate this.
• Keep it Consistent (within the team): Once a team establishes its sizing scale and reference, strive for consistency in its application.
• Regularly Review and Refine: Periodically check if the team's understanding of its sizing scale is still accurate and adjust if necessary.
• Separate Estimation from Commitment: Estimates are forecasts, not guarantees. The team commits to doing its best work, not to hitting an exact number of Story Points.