NEXTUP MADNESS: SCORE 15% OFF KANBAN TRAINING
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, […]
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.
First, let’s explore some of the issues we’ve seen in the past with time-based estimates:
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.
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.
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.
When it comes to relative sizing, there are three common units that Scrum teams use:
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.
When we revisit the 3 pain points of time-based estimates, relative sizing addresses every issue:
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 rsther than hours or days.
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.
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.
How to Become a Great Agile Coach
Coaching, like any great skill, takes time and practice. It requires a continuous cycle of...
Why Would I Need an Agile Coach?
Agile frameworks are simple, but that doesn’t mean they’re easy. Maybe you’re struggling with the...