Should You Estimate in Hours or Story Points?
In almost every agile team I have been working with over the last 15 years the question came up: Should we estimate the work in hours or story points?
Here we will look at the pros and cons and conclude that while there are only a few advantages of story points over hourly estimates, there are many advantages of hourly estimates over story points and that therefore we should almost always use hourly estimates.
1. What are Story Points?
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a feature of a product or any other piece of work.
When we estimate with story points, we assign a point value to each task. The most common values for story points are:
● 0.5: tiny task
● 1: very small task
● 2: small task
● 3: rather small task
● 5: normal task
● 8: rather big task
● 13: big task
● 20: very big task
● 40: extremely big task
● 100: huge task
It is important to note that it does not measure how complex or difficult a task is, but only how much effort in terms of time the task will take. For example, a brain surgery as well as putting on 5000 stamps on letters might both take 3 hours. While it is true that a brain surgery is much more difficult than putting stamps on a letter, this does not affect the story points. Both tasks would have the same story points. That shows that story points really are a measurement of time, just like days, hours and minutes.
Nonetheless, many agile teams prefer to estimate in story points rather than in hours. The reasons for this we will discuss below.
2. Advantages of Estimating in Story Points Over Estimating in Hours
Here we will show the advantages of estimating in story points over estimating in hours.
These are the main advantages of story points:
● Standardize different team members
● Are agile
● Permit planning poker
● Are more reliable
● Allow for faster estimation
● Limit time pressure from management
2.1. Story points standardize different team members
The main argument for using story points over hourly estimates is that they do not depend on the skills and speed of the software developers; story points are the same no matter if a junior developer or a senior developer is working on a task. For example, a functionality might take a junior developer 6 hours, while it takes the senior developer 2 hours. So if we were to make hourly estimates we would have to know first who will be responsible for the task. However, for story points we might assign 3 story points to that feature, knowing that the expected time would vary depending on who is developing it.
2.2. Story points are agile
Some proponents of story points say that they are better as they are agile. But what is agile about them? Only that the story points are being used by many agile teams. But we could implement an agile methodology, without measuring work in story points but in hours. In fact, as we will see below, hourly estimates support transparency, an important part of agility, while story points support intransparency.
2.3. Story points permit planning poker
Some proponents of story points say that they are needed for planning poker, which is an estimation exercise where the whole team estimates the work individually and then compares their estimates.
However, planning poker can be done with hourly estimates in the same way as with story points. Thus, this is not an advantage of story points over hourly estimates.
2.4. Story points are more reliable
Some proponents of story points say that they are more likely to be right than estimates in hours. If that is true depends a lot on what we understand as right. For story points estimates are often said to be right if a task estimated as 13 story points was in fact bigger than a task estimated as an 8 story points task. For hour estimates on the other hand it is not seen as enough if a task estimated as 13 hours takes more than the task estimated as 8 hours, but instead it is asked if the task really took the exact amount of hours. So these are two different standards. So if we define “right estimate” for hourly estimates also as only the relative hour estimates between different tasks, then there is no advantage of story points over hour estimates.
Proponents of story points say that estimates in hours can not be done precisely and that hourly estimates can vary for many different reasons.
However, story points are by no way more precise than hourly estimates. The difference is in the expectation, as story points are not assumed to be precise.
2.5. Story points allow for faster estimation
Proponents of story points say that estimates in story points are faster and they will point to the experience of teams that have reduced the estimation time when switching from hourly estimates to story points.
This indeed can be a big advantage of story point estimation over traditional hour estimation.
2.6. Story points limit time pressure from management
So far we have seen that none of the arguments for story points over hourly estimates hold true, because the same benefits can be achieved with hourly estimates that:
● Are based on a standard developer
● Are not expected to be precise
● Are made in a rough way
However, there is one more advantage of story points that is not generally mentioned: Story points are harder to control for the management. That means that if a developer estimated a task as 5 story points and then he takes 50% more than expected this is harder to notice for the non technical team or management. But if the developer estimates a task as 5 hours and then it takes 50%, or 7.5 hours, this is visible to everyone.
In my experience deciding between story point versus hourly estimates with developers over the last 15 years, I have seen that this is in fact the biggest reason developers prefer story points. This becomes clear in open discussions when developers voice the following concern: “I am not able to estimate the effort for a lot of the functionality precisely, and I am aware that many times in the past I estimated one way and then it took three times longer. So I do not want you to tell me later, that I am to blame because things took longer.”
In summary we see that estimating in story points does in fact seem to have advantages over estimating in hours:
3. Agile Estimation of Hours
When we saw the advantages of estimating in story points over estimating in hours, we were comparing to traditional estimates in hours. However, there is also a way to estimate hours in an agile way. The difference of agile estimates versus traditional estimates are as follows:
● Estimates are based on a standard developer.
● Estimates are not expected to be precise but are rather rough.
● There is no pressure from the management to adhere to time estimates.
● Estimates are made during the planning of the focus cycles, often called scrum planning.
Comparing story points to agile hourly estimates most of the advantages of story points disappear, as we will show below.
3.1. Agile method
First, story points are generally used in an agile way of working. But this is also true for agile hourly estimates, that are made within the sprint planning session. So there is no advantage to estimate in story points.
3.2. Estimate independent of developer
In agile hourly estimates the time estimate is based on a “standard” developer or more generally standard worker. For example, when a senior developer would develop a task in 2 hours and a junior developer in 6 hours, we could estimate a story point of 4. Likewise, we could estimate in hours and assume that a standard developer takes 4 hours. So if for estimating in hours we assume a standard developer there is no more advantage of story points over hourly estimates.
3.3. Fast estimates
The biggest argument for using story points over hourly estimates is that the estimates are quicker to make. However, the difference is due to the fact that often teams estimating in hour are asked to estimate as precisely as possible, while teams estimating in story points are only asked to assign a preset story points number. So slower estimation for hours has to do with the expected precision. If teams are asked to just estimate hours very roughly for example by selecting from preset values, as is done in story points, there is no reason for estimates to take longer.
In agile estimation of hours we also do a rapid and rough estimation without any expectation of being precise. For that reason estimates are made just as quickly as with story points.
3.4. Less likely to be wrong
The reason that story points are less likely to be wrong is that the expectation for them is to be only rough estimates. So if you estimate in 5 story points and in fact it takes 6 story points you would not consider this to be a mistake, while you might see it as a mistake in case you estimated 5 hours and it took you one hour more.
In agile estimation of hours we do a rapid and rough estimation, so that there is no expectation to be precise. So if something takes an hourly more than the original estimate, we would not consider this to be an error. In other words we are less likely to be wrong.
3.5. No pressure from management
With agile estimates of hours the estimates are made without any precision. This is communicated to the management or the product owners, so that they do not use the estimates to later pressure the developers.
So if we do agile hourly estimates in the right way with the right management team then there should not be any undue pressure on developers.
So if we compare hourly estimates made in agile way with story points we see that there is almost no disadvantage:
So the only small advantage of story points over agile estimation in hours is that developers shield themselves even more from potential pressure from management. This is because management misunderstands how story points translate into hours, days, or weeks.
4. Advantages of Estimating in Hours over Estimating in Story Points
If there are few advantages of story points over hourly estimates, then we need to see if on the other hand hourly estimates have advantages over story points.
In fact, there are several advantages of hourly estimates over story point estimates:
● Directly translate into the time it will take
● Have same meaning for everyone
● Are understandable to management and external parties
● Make estimation mistakes and delays apparent
● Reflect progress
● Combine with time tracking and hourly billing
4.1. Hour estimates permit to know how much time a task will take
When we use story points in order to plan how much work we can take on in a sprint, we have to compare story points to team velocity. That process is done as follows:
● Determine how many story points a team can accomplish over a sprint (team velocity).
● Add the story points up and compare them to the team velocity to see if the workload is realistic for sprint.
This calculation takes some time while it should be clear how many hours the team will work and the permitted sprint work load is easy to see.
4.2. hourly estimates have the same meaning for everyone
In estimating with story points teams can decide that a 100 story point task should have a 20 times the workload as a 5 story point task or they might even determine that 1 story point should equal 1 hour. Only if the team does establish such a definition then team members will be able to have a clear communication on story points. But if these definitions are missing, then one developer might assume that one story point corresponds to roughly 3 hours, while another thinks it corresponds to roughly 5 hours. As a consequence they will miscommunicate when talking about story points.
The problem becomes even bigger when communicating between different teams, as each team might have a different definition of how much a story point means in terms of time.
hourly estimates always have the same definition for everybody so there is no miscommunication.
4.3. hourly estimates are understandable to management and other external stakeholders and thus lead to more transparency
A major advantage of hour estimates is that anybody, even if not familiar with scrum and the definition of story points, is able to understand their meaning.
This of course can be a disadvantage if you are a developer and you do not want management to pressure you in relation to the time of the software development. However, the spirit of agile is transparency and collaboration between client and developer and between management and developer. This means that the management and client are expected to be open and transparent with the developer, but also that the developer should have nothing to hide from the client or management.
Estimation in hours makes the estimate understandable to everyone and thus contributes to transparency.
4.4. Hourly estimates make estimation mistakes and delays apparent
WIth hourly estimates, it becomes much easier to see deviations in actual development time from the original estimates. Software developers, who do not value transparency, might think this is a bad thing, but for an agile organization this is a great thing.
An agile organization wants to continuously measure results, self-reflect and improve, and openness in terms of estimation mistakes and delays, helps in that.
4.5. hourly estimates easily allow to reflect progress
The agile team and management want to continuously see the progress of the project. This progress needs to be measured not only with completed tasks but also with tasks in progress. For example, let’s say we have 10 features planned for a sprint and at the middle of the sprint only 1 feature is done, but already 8 features are between at 90% completion. In this case it is clear that in order to get a realistic assessment of progress we need to take account of tasks in progress. That means we have to break down the total story points of tasks in progress into the part that has been done and the part that is still remaining. But this is more difficult if story points are being used instead of hourly estimates.
This is especially the case if during the work on a feature it becomes apparent that the original story point estimation was wrong. For example, what should a developer do if he discovers that a 40 story point task only took him an hour to get it to 90% completion status, or he sees a task that was estimated as 2 story points already took him 100 hours to get it to only 30% completion status. Does he adjust the original and the remaining story points? And how would he do so?
In an hourly estimation these adjustments are far easier as the developer knows how many hours he already worked on the task.
4.6. hourly estimates combine with time tracking and hourly billing
Another advantage of hourly estimates is that they combine with time tracking and billing. Time tracking is required for many organizations, like lawyers, or developers that often bill on an hourly basis. The nice thing is that we can use the same system to plan the effort and then track it while working on it and use it to bill after we have completed the task. This is possible because we can bill clients for hourly estimates but not for story points.
We can see that there are many advantages of hourly estimates over story points.
Also, there are some but few advantages of traditional estimates over agile estimates of hours.
5. Agile Estimation of Hours Better Than Estimation of Story Points
We have seen that there are no advantages of story points estimates over hourly estimates, at least when hourly estimates are made in an agile way, meaning:
● Time estimates:
○ Are based on a standard developer
○ Do not have the expectation to be precise
○ Are made in a rough way
● No pressure from the management to adhere to time estimates.
On the other hand there are many advantages of hourly estimates over story points estimation.
We can compare all the advantages and disadvantages in a comprehensive table:
The table clearly shows that the best way to estimate time of a task is with an agile hourly estimate. For that reason we are no longer using story points internally but always estimated time in hours. Also, for our focus and productivity software, which is called Workiamo, we suggest that the person uses hourly estimates. However, we give the flexibility for people to still estimate in story points, if they so prefer.
Workiamo is a very simple tool that is ideal for anybody that wants to be less stressed and more productive. As you are reading this, we let you access it for lifetime for free! In order to do so, you have to register at www.workiamo.com by entering this code: ILOVEWORK.
