It’s easy to understand why Gantt charts initially are so appealing. They are easy to understand and you see the timespan for all tasks with a start and end date, leaving the project manager with the complete overview of what is being worked on right now and when it is going to be done. So using Gantt charts seems really easy to use when you do release planning. The problem is that the hours that these charts depend on assumes that you have a fixed amount of hours for some person and that none of the dependencies ever change. The hours to do a story of course rely heavily on the person doing it and is impacted by changes in dependencies. This means that to be valid a Gantt chart needs to be updated a lot. On big projects you might even need resources whose only task is to make sure the Gantt charts are up to date. Story points are more stable – and that makes planning with story points a lot easier. 5 points today will be 5 points a month from now or a year from now.
By doing estimation in story points a team can establish their velocity, a measure of the amount of work the team are able to handle during a single sprint. The nice thing about this is that the product owner can use this velocity to plan a release date. Knowing approximately how fast the team is moving s/he can calculate how many sprints it takes to implement the needed functionality for the product to be shipped. Using hours you don’t know the velocity of your team – and that also makes continuous improvement hard. How do you know if any of the teams process improvements work if you can’t measure how fast you are moving. Using points as a measure of output you can easily see if your improvements are working or not. When using hours, both input and measure of output will be hours. Since there are a fixed number of hours every day velocity based on hours can’t really be increased. There is a way it can be increased, but the only way to increase output when using hours is by increasing the number of hours put in. This means making your people “burn the midnight oil”. Studies shows that productivity dramatically decreases when working long hours, and of course – long hours is not the “sustainable pace” that we want.
So points are stable, making release planning possible. Being the measure of output it’s also possible to measure improvements done sprint by sprint. In addition story points are a lot more accurate. Humans are pretty terrible estimating stuff using hours. Studies done as early as the 1940s by the Rand Corporation showed this. A way to overcome this was by putting things in relative sized piles using the Fibonacci sequence when doing estimation, instead of using hours. This method is called the Wideband Delphi estimation method. The same technique is what Planning poker is based on – and most agile teams are familiar with this practice. A quite recent study at Microsoft shows that in the early stages of the project the estimation error using hours is as much as 400% vs 50% using story points.
In addition to all this story point estimation takes a lot less time. According to data presented by Jeff Sutherland story point estimation would cut estimation time by 80% for a CMMI Level 5 company and a telecom company reported that story point estimation with planning poker was 48 times faster than waterfall estimation practices within that company. Since we are reasonably comfortable with relative sizing vs not too comfortable with estimating actual sizes we tend to spend a lot longer time to do those estimations, taking the level of discussions to a couple of levels deeper than you would with point estimations.
The takeaway here is that you should just stop estimating in hours. Numerous studies backs this up – use story points instead!