When it comes to estimation, Scrum doesn’t explicitly give guidance in terms of what units to use. Some teams will use time-based estimates, like hours or days. Alternatively, teams may use relative sizing for estimation. This includes units such as Fibonacci, story points, or t-shirt sizes. From a Scrum standpoint, any of those options work, but which units should your own teams use? In this blog, we will explore the differences between units and help determine which units different teams should be using.
Problems with Time-Based Estimation
First, let’s explore some of the issues we’ve seen in the past with time-based estimates:
Problem #1: Differences in work time vs. turn-around time
Suppose we have a user story that a developer knows will take them 7 hours to do. The 7 hours means 7 hours of work. No meetings, no phone calls, no interruptions, no lunch break, no coffee break, no bathroom breaks; 7 continuous working hours. Start working at 9am non-stop and finish at 4pm. However, when asked to give an estimate, the developer claims it is 2-3 days of work. So, why is the developer giving an estimate of 2-3 days if it’s only 7 hours’ worth of work? The primary reason is that this magical day free of meetings, phone calls, interruptions, and other work most likely doesn’t exist. Additionally, the developers will need to eat, use the bathroom, and take breaks. Thus, for a 7-hour job, it could legitimately take 2-3 days to complete. The problem here is that we often don’t have a shared understanding on whether the hour units represent actual work time or the total turnaround time. This creates confusion in our estimates.
Problem #2: Differences in skillsets
Another challenge we’ve seen in time-based estimates is diversity of skillsets. For example, a user story could take a senior developer 7 hours to complete, but it may take a junior developer 20 hours to complete. Whose estimate should we use? If we use the senior developer’s time, that estimate would probably be too aggressive. If we use the junior developers time, then the estimate may be too conservative, and we may not be approved to do the work. One might mention that we could use the estimate based on the person who’s going to do the work. Yet, in Scrum, we tend to pick up the work in real time, so we may not know which team member is doing the work when the estimate is given. The differences in skillset become very tricky to work with during a time-based estimate.
Problem #3: Nervousness around time-based estimates
When I was working with a software company in Washington, DC, developers were held very tightly to their time-based estimates. In return, they would be so nervous about estimating to the point where they stopped giving estimates. When asked how long a user story would take, the developers would say “we don’t know, we need more details”. When given more details, they would still say “we still don’t know, we need more details.” In their defense, their concept is that if someone wanted an hourly breakdown of work from them, then the developers wanted an hourly breakdown of the need. This in itself resembles the big up-front planning phase that Agile tries to move away from.
For these reasons, many Agile teams are moving away from time-based estimates and toward relative sizing.
Fibonacci, Story Points, and T-shirt sizes
When it comes to relative sizing, there are three common units that Scrum teams use:
- Fibonacci is a mathematical pattern where the sum of the first 2 numbers equals the third. Typically, this means:
- 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 (some teams use ∞ and ? as well)
- Story points are a modified Fibonacci sequence typically with the higher numbers rounded to make them easier to use:
- 0, ½, 1, 2, 3, 5, 8, 13, 20, 60, 100, ∞, ?
- When team use t-shirt sizes, they abstract numbers out of the conversation and the units used are typically:
- XS, S, M, L, XL, ∞, ? (some teams may also use XXS and XXL)
In all three cases, the concept is to estimate the user stories relative to each other instead of being relative to time. For example, let’s assume user story 1 (US1) is 3 story points. If user story 2 (US2) is the same size as US1, then you also give it a 3. If it’s a smaller, meaning less effort and less complexity, give it a smaller number based on how much smaller it is. If it’s larger, meaning more effort and more complexity, give it a larger number depending on how much bigger its. Infinity is reserved for items that are massive projects in themselves. A question mark is used to represent uncertainty in size.
The concept of relative sizing is to abstract time out of estimation. In other words, there should be no direct correlation between the relative size and time. Sometimes teams claim that 8 story points will equal a day of work. But this includes an estimation of time. The whole point of relative sizing is to move away from time-based estimates and focus more on understanding how large the work is.
How Relative Sizing Deals with the Pain Points of Time-Based Estimation
When we revisit the 3 pain points of time-based estimates, relative sizing addresses every issue:
- Work time versus turnaround time: since there is no direct correlation between time and sizing, the issue of work time versus turnaround time goes away.
- Differences in skillsets: once again, since we abstract time out of the estimates, this issue also goes away. For example, even if it takes a senior developer 7 hours to do a job and a junior developer 20 hours to do the job, they could still agree that the job is relatively medium in size give it 8 points.
Nervousness around time-based estimates: when the software company I was working with in DC moved from time based estimate to relative sizing, the developers started giving their size estimates quickly. Developers could respond with a size in minutes rather than hours or days.
Which Units to Use?
I’m not saying you should never use time-based estimates. While Scrum does not dictate which units to use, I can provide some recommendations. See this complexity diagram.
Figure 1 – from https://lostgarden.home.blog/2006/04/03/managing-game-design-risk-part-i/
If the nature of the team’s work falls into the “simple” part of this picture, then time based units like hours or days are fine. Simple work includes a straight-forward and detailed understanding of needs that won’t change, combined with building the product with same way with the same people, tools, and technology time and time again.
However, if the requirements are less known or may change, then it falls into the complicated or complex part of this figure. In the complicated and complex parts of this diagram, the precision of time-based estimates become less effective. Relative sizing allows teams to more quickly factor in the size of the job instead of how long it takes. When it comes to relative sizing, most Scrum teams use story points, but Fibonacci and t-shirt sizes would work as well.