Relative sizing is a technique for estimating the complexity and effort of user stories in Agile Methodologies. It involves comparing user stories to each other and assigning them relative values based on a common scale. In this article, you will learn what relative sizing is, why it is useful, and how to apply it in your Agile projects.
Relative sizing has several advantages over traditional methods of estimation, such as using hours or days. First, it is faster and easier to compare user stories than to assign precise numbers. Second, it reduces the uncertainty and variability that often affect time-based estimates. Third, it fosters collaboration and communication among the team members and stakeholders. Fourth, it allows for continuous adjustment and refinement of estimates as the project progresses and new information emerges.
Relative sizing is a technique in Agile methodologies where the size or effort of one user story is estimated relative to another, often using a scale like story points. It helps teams quickly assess and compare the complexity of tasks without assigning specific time values. This method fosters quicker, more collaborative estimation, enabling teams to plan and prioritize efficiently based on the perceived effort and complexity of user stories.
Different scales can be used for relative sizing, depending on the team's preference and experience. Story points, a numerical scale that assigns values to user stories based on complexity, risk, and uncertainty, are usually derived from the Fibonacci sequence or a power of two sequence. T-shirt sizes are a qualitative scale that assigns values to user stories based on their relative size, such as XS, S, M, L, XL, XXL. Planning poker is a gamified technique that involves using cards with different values (usually story points or t-shirt sizes) to estimate user stories. The team members reveal their cards simultaneously and discuss the differences until they reach a consensus.
Planning, regardless of the tooling, takes ages and you end up with pre-assigned tasks, measured in story points. These points, that should be there to help getting an idea of the complexity of a certain task, are instead used to measure time and that's wrong. Ok, but why are we not using a Fibonacci scale again? Or what about a game of planning poker? Or just give each task a clothing size to simplify its measurement, right? No. This unproductive millimetric measuring and once you set a static metric, people will gradually adapt to go around it. Way of work should be defined at a team level by its people, not by the?company. This is true also for sizing tasks, just let your team figure out what to do, I assure you they will find a way.
To apply relative sizing, you need to start by defining a reference story. This should be a simple and well-understood story that has been completed or is about to be completed, which you can use as a benchmark for other stories. Then, for each user story, compare it to the reference story and decide whether it is smaller, larger, or equal in complexity and effort. Assign it a value on your chosen scale accordingly. Additionally, review your estimates periodically and adjust them if needed. You may discover new information, dependencies, or changes that affect the complexity and effort of user stories. Furthermore, you can learn from your actual performance and feedback and calibrate your estimates accordingly.
There is no truth behind relative sizing but it is a good way to approximate the lenght and complexity of a task to be executed. I personally try to follow these steps: 1. Take similar tasks (both complete and incomplete) and group them. Take in consideration a couple the most recent completed tasks, not every of them. 2. Order inside these groups for complexity - just rule of thumb you don't need to be precise. 3. Now take the completed tasks off the equation (we just needed them to size the others). 3. Take the most complex incomplete tasks and understand if they can be broke down in smaller (easier) ones. 4. Reorder the list 5. Size the most easy task 6. Size the others by the amount of easy tasks that fit into the complex ones.
Relative sizing is not an exact science, but a skill that can be honed with practice and collaboration. To help you get better at relative sizing, involve the whole team in the estimation process as they have the best knowledge and insights about the work involved. Additionally, use multiple rounds of estimation to refine and validate your estimates. Techniques like planning poker, affinity mapping, or dot voting can be used to facilitate this process. Furthermore, avoid anchoring and bias when evaluating each user story independently and objectively. Use a range of values instead of a single value to account for uncertainty and variability. Finally, track your estimates and compare them to the actual time and effort spent on user stories to identify any gaps or discrepancies. You can use metrics like velocity, burndown charts, or variance analysis to monitor your progress and performance.