If you are a practicioner of Scrum you've surely heard of 'point-based estimation'. I find this to be the most difficult concept to understand when it comes to Scrum, but also one of the most powerful aspects. If you want to know more about this type of estimation, you've come to the right place! Hopefully I can enlighten you with the things that I picked up when I struggled with the concept myself. I will also try to answer some of the more frequent questions. Feel free to add your own comments below the post. Please note that 'points' are used in this post, but they are sometimes also named 'story points', 'complexity points' or 'functional points' (although this is often something different).
Traditionally, many teams use time-based estimation to estimate the complexity of tasks. This simply means that tasks are estimated in terms of the amount of hours or days they'll require (give or take) to finish them. Point-based estimates, however, use an abstract unit called a 'point'. It has no objective meaning, but it does when the tasks are compared. Tasks that are considered to be '10-point' tasks are twice as complicated as '5-point' tasks. But why would you ever want to use such an abstract unit? I'll explain, but let me first explain the problem with time-based estimates.
The problem with time-based estimates
Time-based estimates are usually acceptable for small tasks that are easy to understand and explain. But for more complicated tasks, it becomes increasingly hard to give solid estimates. Suppose, for example, that we are building a webshop. It is fairly straightforward to estimate the time it will take to implement a (simple) shopping basket. The estimate might be off a bit, but a good developer should be fairly accurate. It is an entirely different story when we are going to implement support for electronic payment (creditcard, iDeal, etc). This usually requires some external API that needs to be accessed. Estimating these tasks is still possible, but only when you know all the (relevant) details. To gather these details, a so-called 'waterfall'-approach is often used. This means that analists or members of the team start to set up a functional and technical design for the webshop. The product owner (customer), in turn, will be asked to provide a list of all the requirements he or she desires.
If you've read a little bit about Scrum, you'll already know that Scrum takes a very different approach. It accepts that the approach above might work, but usually won't. The product owner will usually not know all the requirements upfront or is not willing to sign off on complicated design documents that are hard to understand. Also, this approach is very rigid and makes changes during the project undesirable as they increase the project's cost or affect the deadline. In addition, the analysis phase that is required to hammer down all the details will be very time-consuming and result in a large number of paper artifacts, like design documents, that have to be continuously updated. In short, a recipe for disaster. Which is also what happens to most of these projects. In fact, more than three-quarters of all projects go over-budget and over-time. So apparently, taking all this time to analyze and hammer down the details still does not result in accurate estimates.
Forget hours, estimate complexity
So estimating in time apparently does not work so well. The alternative that Scrum (amongst other methodologies, by the way) provides is to estimate the relative complexity of tasks. In the context of Scrum, this means that the team will estimate the items in the backlog (user stories) based on their complexity. The estimation will be done based mostly on the user stories themselves. As user stories are simple sentences ('as a customer, I want to put products in my basket so that I can order many items at once'), the team can use little more than their 'gut feeling' and lively debate amongst themselves to reach a consensus. There are good methods for stimulating this debate, which is crucial to achieve accurate estimates. Planning Poker is a good example, which I will describe in more detail in another post. The team simply assigns points to all the items in the backlog, thereby ordering the items by their relative complexity. Also note that product owner can use this information to re-prioritize the backlog.
Now, you may wonder what these points actually mean. Well, nothing really. But this is where the magic happens.
Measure velocity, know your speed
Based on the point estimates, the team can decide how many points they can tackle in a sprint. We usually use 1-week sprints. For the first week, the team usually is not very sure how many points they can handle. So they'll just select the items in the prioritized backlog they can finish in the sprint. During the sprint, the team will perform work which, hopefully, finishes user stories. At the end of the sprint, the team can look back at the backlog and the sprint backlog and determine how many items they completed in the sprint. By adding up these points, they now know their sprint velocity. This value represents the number of points the team can complete in a sprint. When selecting the sprint backlog for the next sprint, the team can use their measured velocity to select the items they believe they can finish. As sprints progress, the measure of velocity becomes more accurate (and usually also increases). The team might even use their velocity from one project to estimate their speed for new projects, as long as they compare the user stories for the new project to user stories from the previous project. Otherwise, the concept of 'relative complexity' is lost. You can't compare apples and pears, after all.
By now, you'll understand how fundamentally different this approach to estimation is. Rather than estimating time, the team estimates complexity. Not in terms of hours, but in terms of their relative complexity to other user stories. In themselves, the points have little meaning. But they become meaningful once the team gets underway and sprints start and finish.
'But I need to know hours...'
In an ideal Scrum-world, the entire concept of 'hours' is not even communicated to product owners. The problem with hour-based estimates is that they give a false sense of security. The fact they are 'estimates' is usually completetly lost. There are so many reasons to not use hours, that i'll probably write a post on that once. But anyways, that's why Scrum coaches don't want to talk in terms of hours. In Scrum, the product owner works with the team through a prioritized backlog. The product owner is free to add new items or remove existing ones, which might change the scope during the project. That's ok. The product owner decides when he or she is satisfied, and the team starts work on other projects and the product owner pays for the time the team spent.
But in the real world, product owners or even managers internal to your organization will usually want to know how many hours the project will take. This is the only way (in the traditional sense) to calculate the cost of the project (hour rate * hours). Sadly, there is no silver bullet for this. Scrum projects are, almost by definition, undetermined in length. The project ends when the product owner is satisfied. But this requires a lot of trust in the team and product owners usually work with budgets that they have to get signed off from their CEOs. The best approach, in this case, is to simply sell a number of team sprints (at least 3) to the product owner. The scrum coach can set up the product backlog with the product owner and the team can estimate the complexity in points. For the first sprint, the team selects what it can take on. After the sprint, the product owner and the team will have a general idea of the velocity of the team. This allows the product owner to re-prioritize the product backlog if they wish to do so. The team can then continue working through the sprints. At the end of the 'project', the product owner can decide to purchase the team for additional sprints. Preferably, the product owner should have some idea of the team's velocity before prioritizing the product backlog for the first sprint. This allows them to remove items that are too large or not important enough. The velocity can be measured during the further sprints to further guide the product owner.
Time-based estimates are used by many teams. No matter how much time is spent estimating projects upfront, they usually fail because we are very bad at estimating abstract, complicated concepts upfront. A different approach is to use 'point-based' estimation, which uses an important concept called 'empirical control' to measure the speed at which a team can complete work. This 'velocity' is then used to select the amount of work a team will finish in one sprint. This requires that the team estimates, for all the items in the product backlog, how complex the items are relative to each other. This is done with 'points'. The advantage of this approach is that it allows teams to actually know how much work they can finish, rather than having to estimate it upfront. In practice, it might sometimes be difficult to sell this to product owners. But in this post I also presented a way to do this (there are others as well).
Give it a try! You'll like it, especially when you use techniques like planning poker.