When it comes to task estimation, there are basically two ways to go – the classic one being time effort expressed in hours, and the newest being story points. Both approaches have their advocates and critics, but what are their main advantages and disadvantages? In this article, I will try to answer this question – but first, let’s start with describing the two methods.
Table of content
- Time effort estimations
- Story points estimations
- The idea behind the story points
- Team capacity – How to estimate the sprint?
- Why does the estimation differ so much from burned hours?
- The problem with time estimations
- The problem with story points
- Story points vs. hours
- Summary
Time effort estimations
As the saying goes, time is money, and this is certainly true if you work based on a time-and-material contract. What’s more, time is the value that we all know well – an hour is the same whether it’s spent in Europe, Asia, or America. This makes time estimation very predictable for the client when estimating the cost of functionality and the expected return on investment.
It is the responsibility of the development team to try to estimate how long it will take them to implement and test the new functionality. Here’s an example of what that might look like:
PM: We have to add this button to the main page. How long would it take?
Dev: About four hours.
PM: What about tests?
Tester: One hour.
PM: Let’s assume that there will be something to be fixed after our tests, so let’s set the estimation for 6 hours. Ok?
Dev + Tester: Ok.
Even if the whole team is present during the estimation, the final call is still up to the developer implementing the feature.
Story points estimations
In story points estimations, the team doesn’t estimate the exact time needed to implement the functionality. Instead, they estimate the difficulty of the task. Typically, numbers from the Fibonacci sequence (1, 2, 3, 5, 8,…) are used for this purpose. At first, all the team can estimate using their intuition and first impressions of the task. If the differences are significant, then the team members with the highest and lowest scores justify their scores to the others. After the second round of estimation, the highest score is taken into account.
Here’s the same example again:
PM: We have to add this button to the main page. Are you ready to estimate? Ok, let’s go. 3, 2, 1… go!
PM: Ok, we’ve got 3, 5, 2 and 8. John, why did you give it an 8?
John: It has to be added to multiple screens etc.
PM: Paul, why only 2?
Paul: It’s just a button after all, we have plenty of those in the application.
PM: Ok, one more time. 3, 2, 1…. Go!
PM: Ok, 3, 3, 2 and 3. Ok, so the 3 is the score.
In this way, the whole team is responsible for the estimation.
To make the estimations even more independent, we can use Planning Poker – special cards are used to score stories.
The idea behind the story points
The whole idea behind story point estimation originated from the fact that it is almost impossible to guess how much time it will take to finish a task. If the task involves changing some labels it shouldn’t take more than an hour (including tests and going for a coffee :)). But what about implementing some new features? It could take just a couple of hours if everything goes smoothly, but if not, it could take as long as a week.
The more details known about the task, the less uncertainty there is in the estimation. But sometimes uncertainty can only be eliminated by actually starting work on the issue. That’s why estimating for tasks that take more than four hours long is usually not very accurate.
In time estimates, it is considered a good practice to estimate with either even or odd numbers – typically even, but never both. One-hour tasks are the exception. If a developer says that a task will take him five hours, then assume 6 to increase the comfort of work.
In story points, the team estimates the difficulty of the job using comparisons. For example, is an 8-story-point task harder or simpler than a previous task? If yes, give it more points, etc. Knowing the capacity of the team, we can assume if it’s possible to implement the task in the sprint or not.
Team capacity – how to estimate the sprint?
Team capacity is a value showing us how much the team can implement in the sprint. It is used both in hour estimates and story points.
Hour estimates
In hour estimates, it is quite simple – but there are a couple of things to consider:
- Is the developer involved in the project full-time or part-time?
- How long will the sprint take?
- How much and what sprint ceremonies are here in the project calendar?
- Does the developer attend other meetings outside the project?
- Has the developer planned a holiday or days off in the following sprint?
- Should we include some time for the hotfixes on the production?
Let’s assume that we have a two-week sprint with typical scrum meetings (daily, retrospective, review, planning, refinement and demo) and apart from these no other disturbances for the developers. So we have 80 hours of work in total, reduced by about six hours of scrum meeting for the whole sprint. This gives us 74 hours of work on the project, but probably not all the tasks will be done within the estimated time, so we typically assume that only 80% of the available time of the Developer will be the efficient work. This amounts to 64 hours that we can plan for one developer. Then, this value we can be multiplied by the number of developers in the team to calculate the entire team’s capacity.
The same goes with the deadline of the project – we have rough estimations of all the features that we want to deliver and, using this time capacity, we can provide a possible date of delivery.
Story points
In story points, estimations are quite similar – the same aspects affect the team capacity. First, the developers have to assume how much they can do in one sprint – for example, one bigger task and a couple of smaller ones. A good practice to learn the time capacity is to take fewer tasks in a sprint to have the comfort of adding some new tasks from the backlog. Usually, after two or three sprints, the team knows the project and can better estimate it. Then, their plan for the sprint will be very likely to be delivered completely.
But how to estimate project deadlines? The same way as before – we estimate the features left to deliver and then, by comparing the story points with the whole team’s capacity, we can estimate the date of delivery. To increase the accuracy of the deadline estimation, we should divide the features into smaller tasks that have as few story points as possible.
Why does the estimation differ so much from burned hours?
As described at the beginning, the crucial difference between time and story points estimation is that the developer is responsible for estimations in the former, and the entire team in the latter.
Have you ever:
- Been ill, but still willing to work?
- Got into an argument with the family or wife/husband?
- Had a bad sleep?
These are a couple of situations that could affect your efficiency at work. A developer is able to come up with a solution, but at this very moment nothing comes to his mind – and the clock is ticking. This can lead to frustration which, in turn, will result in low code quality and bugs – simply because I have to finish my task within my time limit – I said I would do in time, and I have to deliver.
An interesting paradox to mention: tasks are almost never finished before the time limit – they are always completed exactly on the time or later.
The problem with time estimations
There is a problem with one person having sole responsibility for the estimate. What if he or she gets ill and we still have to implement the feature? The same situation happens when all tasks are estimated by the team leader and not by the whole team. So let’s assume that John estimated that he would do this task in 8 hours. But when Paul tries to do it, he could do it faster (best case scenario) or it would take him longer. This is something that we should be aware of when using the time estimations.
There is another difficulty with time estimation: it involves some finger-pointing – who is better in the team, and who is the bottleneck. If one developer estimates a task for two days and another one estimates it for 4 hours, it could (and usually will) create conflict that this developer is weak and shouldn’t be in the team. This is why time estimations can create a toxic environment in the team.
Story points eliminate this problem – the task has to be discussed within the team and everyone in the team has to agree on the estimate – no matter who will implement it in the end, it is still correctly estimated.
The problem with story points
Story points are not always clear – especially for the clients, who find it very hard to understand their benefits. Clients prefer time estimations because it is something they can relate to. Some teams try to map the story points to hours – for example two story points correspond to a task that will take 2–4 hours, and 3 story points can be mapped to tasks from 4 to 8 hours long, and so on.
This is a hybrid approach to task estimations which generally shouldn’t be applied, but could make it easier for the client to understand all these Fibonacci numbers that we use for task estimations.
Story points vs. hours
Pros
Cons
Summary
Now you should see the differences in story points and time estimations. I hope you will find it easier to choose the best approach for your project.
