Story Points or Hours?

A question I'm often asked by clients and students alike is, "why estimate with story points?" Why not just use hours? It's a good question and worth a conversation. Certainly estimating with hours (or time in general) feels normal. We've been doing it this way for a long time and we've gotten good at it, right? As I think back on my pre-Agile days when I was either a developer or a project manager, I struggle to remember any time-based estimates that were remotely accurate, despite best efforts to be accurate. So why is that? Is every developer in history lying to us? Doubtful. So what are we missing? It's actually simpler than most people think. I'll use my own personal experience to demonstrate.

Let's say my boss asks me for an estimate to complete a small and relatively simple task. I give it some thought and think to myself that it should reasonably take me 8 hours to complete. In my mind I'm making a fatal assumption. That assumption is that all 8 of those hours are going to be of a relatively similar level of productivity. Now ask yourself this question... Are all 8 of those hours likely to be of a similar level of productivity? The answer is, not likely. Why? Because things come up - all the time. What could happen in the world of work, or the world of life, that could make one of those 8 hours less productive than anticipated? Might you face production issues? Last minute meetings? Maybe you couldn't sleep the night before and you're just tired today. Maybe you ran out of coffee? Maybe you get sick. What if you lost power or internet? What if your computer crashes? What if there was a fire drill in your building? What if you got a bad personal phone call? What if the weather is bad? What if, what if, what if??? The problem here is that none of the aforementioned challenges (and the millions I didn't list) are predictable. You can even pad those estimates and you'll still be way off. And the more difficult / larger the task is, the less accurate your estimates will be. So estimating in time is, at best, problematic.

How are story points different? Well, for one, time does not factor in the estimate. Story points are decided based on a technique called relative estimation. This technique plays to a strength we have as a species. We are good at comparing things to other things. We are not good at predicting the future - a requirement for time based estimation. If you were good at predicting the future, you wouldn't be wasting your time reading this post. You'd be a lottery winner sitting on a tropical beach thinking about your next gourmet meal. I digress...

Here's a simple example of relative estimation. If I were to put a golf ball and a softball on a table in front of you, you could instantly tell me which ball was bigger. And with a little bit of study, you could *roughly* tell me how much bigger the softball is than the golf ball. You could also tell me roughly how many of those golf balls could fit inside the softball. Let's say for argument sake, you think you could fit 8 golf balls inside the softball. And you decided that the golf ball was small enough to warrant 1 story point in size. If you can fit 8 golf balls into the softball, then the softball = 8 story points.

When developers use this technique to estimate work, they are not thinking about physical size of the work like the softball/golf ball example. They are thinking about the effort to complete the work. The effort based estimate is arrived at by the entire development team, which hopefully has been organized as a cross functional team (e.g., in the world of software that would mean a single team has coders, testers, architects and UX folks on it). This collection of experts considers the combined effort to get a feature done per the team's Definition of Done. Effort is comprised of 4 measurements; volume, complexity, uncertainty and risk. The team considers how much or how little of these elements are present in getting the work to done. If analyzing 2 pieces of work, and work item A is low effort in the team's view, they may give it 1 story point. If the team feels that work item B is 5x the effort of work item A, then work item B may be estimated as 5 story points.

So how does this help me if I'm in a leadership position and need to know when things will get done? The answer is less complicated than we may think. If we track how many story points a team completes in a Sprint (some call this "velocity"), we can forecast based on that number. Here's a simplified example: if a team has a consistent velocity of 20 points per Sprint, and the remainder of the work to be delivered adds up to 200 story points, you can reasonably postulate that it will take that team 10 more Sprints (200 points remaining / 20 points per Sprint) to complete the remainder of the work.

Now before you go considering that formula to be absolute, bear in mind that things always come up. Scopes change. Customers ask for new things, leadership asks for new things, developers learn we need to build things we didn't initially think of, etc... Estimates change. As teams complete work and learn more about that work, previously provided estimates may increase or decrease based on new information. So the formula is not absolute. There will be variance. But these variances are easier to take, for a few reasons. 1) if new work items are identified by stakeholders, management or developers, it was valuable work that is needed, and will make your delivery more successful. 2) if estimates change because of new learning/experience gained by developers, there could be as many estimates that decrease as there will be that increase.

There is even a third option to consider in the world of estimation, and that is to not estimate at all. I know, on the surface that sounds crazy - for many reasons. Believe it or not, it is not a completely insane idea. It does however require that teams form work that is all of very similar effort. It requires teams to break up work into equal chunks of effort. Then tracking their progress simply becomes counting how many work items are done in a Sprint. More on this later.

One final note on estimation, which ever way you choose to go... If your teams are not predictable, neither will be your long term forecasts. So part of the goal should be to do whatever we can to assist our teams in becoming predictable. People being assigned to multiple teams, or people wearing multiple hats are the surest way to make your teams unpredictable. Imagine the business advantages we would have if our teams were consistent in their delivery and were highly predictable?