If you are working on an Agile project, you might wonder how to estimate the costs of your tasks and deliverables. One common method is to use relative sizing, which compares the complexity and effort of different work items. In this article, you will learn how to use relative sizing to estimate Agile project costs and what benefits and challenges it offers.
Relative sizing is a technique that assigns a numerical value to each work item based on its relative complexity and effort compared to other work items. For example, you might use a Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or a t-shirt size (XS, S, M, L, XL, XXL, etc.) to rank your tasks. The idea is to avoid absolute estimates that depend on time or money, and instead focus on the relative differences between work items.
Relative sizing, often used in agile ways of working, can bring several challenges: Lack of Precision: Relative sizing doesn't provide precise estimates in terms of time or effort. Instead, it focuses on comparing the size of one task relative to another. Misinterpretation: Stakeholders who are not familiar with the concept of relative sizing may misinterpret or mistakenly compare them to traditional time-based estimates. Difficulty in Benchmarking: Without precise time estimates, benchmarking against past performance or industry standards becomes challenging. Regular retrospectives and adjustments can help mitigate some of these challenges and improve the accuracy of estimations over time.
In Agile project estimation, relative sizing employs story points based on complexity, with historical team velocity aiding in estimating deliverable story points within a timeframe and determining the necessary iterations. Multiplying the iterations by the cost per iteration provides a preliminary project cost estimate. Regular reassessment accommodates evolving priorities in Agile development, ensuring adaptability throughout the project's lifecycle.
Absolute sizing is more prone to our own biases: we tend to think we can do a task faster than we actually will. Also, it’s easier for the human mind to compare items than to think of all the scenarios for achieveing that task.
I don't find relative sizing to be very helpful in estimating costs. The value is in figuring out team capacity, and that changes sprint by sprint typically. You also discover hidden things when you dig into a story that makes the inherent complexity score somewhat variable. The usefulness is for the sprint or project as a whole because the average points smooth over time. My experience is that the team size is usually fixed (or nearly so), and that is where you get the cost estimates from. The project can be estimated at the macro level early on, and will get more precise over time.
In my view, Relative sizing is an Agile estimation technique where work items are compared based on their complexity, rather than assigned absolute units like time or cost. Using scales such as the Fibonacci sequence or t-shirt sizes, teams collaboratively estimate the size of tasks during sessions, guided by past experience. Story points, a common unit in Agile, represent effort. Estimates are iterative and refined as teams gain information. This promotes collaboration and adaptability in project planning, aiding effective prioritization. By focusing on relative complexity, it facilitates accurate estimates over time, enhancing project success.
To use relative sizing, you must have a list of work items, such as user stories, features, or tasks, and a reference work item to serve as a baseline for comparison. To assign a size value to each work item, you can use planning poker, affinity mapping, or t-shirt sizing. Planning poker is a collaborative game where each team member uses a set of cards with size values to vote on the size of each work item. Affinity mapping is a visual method where the team sorts the work items into groups based on their similarity in size. T-shirt sizing is a simple method where the team assigns a t-shirt size to each work item based on their intuition and experience. The team can then convert the t-shirt sizes into numerical values if needed.
Relative sizing in agile projects involves estimating the size of tasks or USs relative to each other rather than using absolute units. To use relative sizing for cost estimation: -Pick a Base Task where you select a simple task and give it a value of 1. - Compare Others: Compare other tasks to this base task. Use a scale like 1, 2, 3, 5, 8, etc., indicating their relative size. - Measure Team Speed: Review how many of these points your team can finish in a fixed time (ex. Sprint). - Calculate Cost: Estimate the time and cost for each point based on your team's speed. - Modify when needed: Adjust your estimates as you learn more about your team's velocity.
Relative sizing in Agile project cost estimation involves assigning story points to user stories based on complexity, calculating team velocity, estimating costs per story point, multiplying total story points by cost per point to estimate project cost, and iteratively refining estimates. Story points are relative measures of work size. Team velocity, derived from past performance, represents the average work completed per sprint. Costs per story point consider team capacity, hourly rates, and project budget. The total cost is estimated by multiplying total story points by cost per point. Refining estimates during the project ensures accuracy, accounting for new insights and scope changes.
Relative sizing is a Agile which allows a team to identify the velocity of a Sprint. The velocity in terms of the time taken to accomplish tasks in given Sprint. The tasks can be mixture of Complex and Simple stories. The complexity is defined in terms of count in fibonacci series of 1,2,3,5,8,13. The initial sprints where we may or may not achieve what we planned but we can get the count which we are able to accomplish in a Sprint. Say you have 4 stories with story point count as 13 and 6 minor stories with count as 3. So we were able to achieve 70 story points. So we will need to maintain this count in upcoming Sprints. If we fail to achieve so, we are either lacking in speed or our estimations are incorrect
Relative sizing is not merely a function of how much effort is required to complete a given epic, story, or task, it is also a function of time...i.e., how much work can my sprint team accomplish in a given period of time? It is of little value to customers or product development teams to size work unless they know how much work can be accomplished in a fixed period of time. This is why velocity is so critical, and is an integral part of the relative sizing process.
Teams create a historical record of finished projects and the associated story points over time. The average number of story points finished in a sprint, or velocity, gives the team an idea of how big it can get. This information is useful for estimating in the future.
Relative sizing offers several advantages for estimating Agile project costs, such as reducing uncertainty and variability, encouraging team collaboration and communication, supporting iterative and adaptive planning, and improving the accuracy and reliability of estimates. This is because it focuses on the relative differences rather than absolute values, involves the whole team in the estimation process to foster a common understanding of the work items, allows the team to adjust the estimates based on feedback, and reflects the team's actual performance and capacity.
Relative sizing is simple to perform and provides flexibility to the team. Unless the work is trivial, routine or already known - it can be challenging to provide accurate to the day/week estimates. The time spent in trying to put together more accurate estimates is better spent in refining requirements or doing POCs. Relative sizing can also reduce the tendency for estimates to be weaponised to be used against the team e.g. why isn't a specific date/milestone being met.
In my experience, relative sizing is very useful. When the team discusses the task and max/min estimate dispersion, it helps uncover hidden amounts of work that nobody has thought about.
The question should be how would you verify the the cost estimated by relative sizing. The confidence interval of our claim is vital. However, relative sizing is very important to get a ballpark estimate of the project. Few factors that you must consider: 1. Experience of team - do they need training on technologies used? 2. Cross team collaboration and response - how many separate teams work on the same. How swift is the response from other team? In the absence of an overarching authority, this becomes even more important. 3. This is an open question. Relative to what? The subjectivity of this question will determine a large part of overall cost.
Using relative sizing can have a positive impact in multiple areas. - promote team collaboration: relative sizing can trigger discussion about the task which can improve knowledge and involvement within the team. - facilitate prioritization, therefore informed decisions can be taken - provide transparency: provide visibility of complexity to everyone. - reduce bias and anchoring effects: by focusing on relative comparisons, teams are less influenced by factors such as individual perceptions or external benchmarks. this approach helps in making more objective and rational decisions during planning.
Depends on the Agile transformation model. When a team is transitioning from Waterfall to Agile, it is a rigorous exercise to educate team about time-boxing the sprint activities into logical blocks. As per Industry standard of Agile transformation, a team within 5-6 Sprints can see the difference of adhering to relative sizing in the following areas: 1. All efforts captured and showing Teams gradual progress through different ALM tools being used for daily tracking and progress 2. History of Grooming and Planning captured which shows how the team’s velocity has improved across the board. Sprint commitment vs Sprint completion should show better productivity 3. Effectiveness of team’s capacity through Sprint Burn-up and Burn-down charts
Relative sizing is not a perfect method and has some challenges to be aware of. It requires a clear and consistent definition of what constitutes a work item and how to measure its complexity and effort. Additionally, the quality and availability of the reference work item and the size values used by the team can influence its accuracy. Subjective factors, such as team members' preferences, biases, or emotions, may also play a role in its outcomes. Moreover, external factors such as dependencies, risks, or constraints that affect the project costs may not be taken into account.
The main challenge is the lack of understanding of the purpose and applicability of relative estimation. Many team use story points to plan the next sprint, which is wrong and causes frustration and gives bad results as this method is just not mentioned for such application. Instead a precise calculation of sprint capacity in m/hours and detailed estimation of tasks in m/hours should be used to plan a sprint, and user stories should be reserved for product backlog estimation and long term planning.
Teams often get into the details of a work item resulting in bottom-up estimations. The fear of failure to deliver within time, cost and quality add to the challenge. Teams that are fearful of failure are often challenged in performing effective relative sizing. In my experience, teams that are under constant stress to estimate accurately to avoid delivery delays would not perform relative sizing well. Organisations that cant embrace failure and learn from it find it difficult to adopt relative sizing. As a result, teams overestimate expecting to deliver on time or underestimate to meet demands of delivering more. In both instances the benefits of the technique are missed. Often, relative sizing may take a few iterations to get it right.
One challenge of relative sizing is ensuring consistency across team members, as different people may perceive the same task differently. Another challenge is the temptation to equate relative sizes to specific time or effort, which defeats the purpose of relative estimation. Estimating large tasks can be particularly challenging, as their relative size compared to smaller tasks may not be as clear. Finally, maintaining the reference story's relevance over time can be difficult as the team's understanding and context evolve.
Setting the expectation that this is not an absolute estimation is key. It takes time for teams to be comfortable in relative estimation and more time the lack of understanding by business puts a lot of pressure on teams.
The challenges of relative sizing are that the sizing is done by usually the senior members of the team and defined a work package to be much easier to execute while the actual work is done by the juniors who are not at the same level of competency as the seniors in the team. Relative sizing is relative to the engineer building the system at the last stage however it cannot be accurately used for defining the size at the macro or a program level.
Relative sizing is not enough to estimate project costs, as it does not provide information on time or money required for each work item. To convert relative sizes into project costs, one of the following methods can be used: velocity, cost per unit, or conversion factor. Velocity is the average number of size units a team can complete in a given time period; cost per unit is the average amount of money spent to complete one size unit of work; and conversion factor is a ratio that converts size units into time or money units. Historical data of the team's velocity, cost per unit, and conversion factor can be used to calculate project costs based on total size of work items, duration of the project, budget of the project, and desired unit of measure.
Project costing with relative sizing requires a few other parameters such as velocity and the ratio between Committed vs Delivered (CvD) items. The capacity of the sprint could be a staring point of calculating the cost of each sprint. This could be supplemented with overhead costs. Dividing sprint the cost by velocity will provide the cost per story point. It is also important to factor in the actual delivered items in terms of CvD. Similar to relative sizing a relative value to business indicator is sometimes used. Thus, indicating the value delivered. This value could be mapped to a commercial figure. Using cost of a sprint, the number of sprints needed to deliver a project would now indicate the total cost of the project.
More important than the answer to this question might be its pitfalls to consider- 1. Agile teams are often organized as continuously producing 'value streams', yet dollars often fund finite 'projects'. 2. Agile teams decompose work into units like 'epics' and 'features' that don't directly map to projects. 3. Relative sizing is different per team, so story points cannot be simply summed across teams to determine 'total cost per point'. 4. Story points only account for team level labor costs. What about software, management, facilities, other costs? 5. Story pointing is based on team estimation, which can be influenced by any number of factors. 6. The person looking at your project costs shouldn't need to understand all this complexity.
Converting relative sizes into project costs involves several approaches: 1. Historical Data: Use past project data to correlate relative sizes with actual time/cost. 2.Expert Judgment: Rely on team expertise to estimate time and cost based on complexity. 3.Cost-Per-Point: Assign a cost value per point based on historical or industry standards. 4.Iterative Refinement: Start with rough estimates and refine as the project progresses. 5.Risk-Based Estimation: Account for uncertainty and risk in estimating costs. 6.Monte Carlo Simulation: Use simulation to generate probabilistic cost estimates. 7.Each approach requires a combination of data, expertise, and refinement to accurately estimate project costs.
Converter tamanhos relativos em custos de projeto é uma tarefa complexa que requer a combina??o de estimativas relativas de esfor?o com dados históricos e conhecimento sobre a capacidade e a produtividade da equipe. Este processo envolve várias etapas e pressup?e que você já tenha concluído a estimativa do tamanho relativo dos itens de trabalho (por exemplo, usando tamanhos de camisetas, pontos de história ou a sequência de Fibonacci). Converter estimativas de tamanho relativo em custos de projeto é uma abordagem que exige tanto arte quanto ciência, envolvendo julgamento, experiência e uma compreens?o profunda da equipe e do projeto.
Dependence on the historical data of velocity lacks precision as each project is unique. Also the fact that each team member will have a different perspective of the user stories complexity and will result in inconsistent estimate.
One thing to remember is this - Size values are just a forecasting tool. They are not performance indicators. If we try to measure the performance of a team or an individual by counting how much size of work is done in a period, it creates a culture of inflation, where the team bumps the estimates up to meet the expected performance. If one wants to measure performance, they could resort to other reasonable metrics like lead time, flow efficiency, throughput, etc. Don't link any performance with the size of the work item. Use the sizes only for forecasting.
There is theory, there is reality. Dont shy to experiment what works best for your team. Pick a reference task that everybody understands within the team. Check on that reference task at a later point again - is it still useful for the team, is there a better option? We evolve over time, so should your methods and way of working. We always tell to not compare the teams velocity to other teams, yet it still will happen. Instead, focus on predictability (How much we plan vs How much we get done). Now we can have a very different discussion. Overdelivering is not inherently "good" either. Predictability should be ideally between 90% and 110%
You can use relative sizing to estimate Agile project costs by assigning a size value to each task or user story relative to a reference story. Then, estimate the cost based on the size of each item, considering factors like complexity and effort required. This approach allows for more accurate cost estimation in Agile projects. Note: I'm not a great fan of converting LoE in hours and trying to derive the cost in my agile transformation, I rather have story points based on the size by relative measurement and team would get better at estimation after few sprints.
Instead of trying to "improve" estimation, we should find ways to achieve what we want without estimation because estimation is fundamentally flawed in any not trivial software development.
Estimates are a waste of my precious time and yours as well, short stories will show you the real velocity! Everything else is daydreaming, welcome to the real world my friends we all know creators are awfull at estimates, you cannot experiment in such conditions, ask a rock band how long they be in studio for an album, they're answer will be from 6 months to 2 years! Software is creation just another art with a bit of mathematics.