Defining Estimation Methods

Defining Estimation Methods

The first thing you need to know when working with estimates is that story points are not hours. Most confusion around estimation comes from that phrase, mostly because story points are intentionally vague. Hours aren’t complicated; there are 24 of them in a day, a work-week contains 40 of them, and they’re consistent. But story points, that’s where we throw a wrench into the works. We understand when something can be completed in terms of hours; if a task takes me 16 hours to complete, it’ll take two days of 100% dedicated time to complete (or so I’m estimating). With story points, if I tell you a task is 3 of them, you have no idea how long something will take. We’ll cover that more later.

But even estimating in hours — for all their consistency — can lead to some misinterpretation. In this second part of our estimation series, we will discuss the general differences between estimating using hours vs. story points.

‍

Hours

There are essentially two kinds of estimation that include hours…

‍

1. The Days Someone Thinks It Will Take Even Though You Said “Hours”

I used to do a lot of stage management work and one thing that the team always made sure you knew was “Chances are you will make a mistake and everyone will see it; it’s okay, and the worst thing you can do is freak out on stage when it happens.” The same applies to when someone (sales) reads “hours” and thinks “days.” It’s going to happen, it’s okay, and the worst thing you can do is freak out. It’s easy to jump from X amount of hours to Y amount of days when you know that a standard work day has 8 hours.

That said, if someone says a task takes 16 hours and you think it’ll be done in 2 days, you aren’t on the same page, so it’s important to make the distinction.

‍

2. The Total Development Time You Actually Meant

In my experience, this is typically what is meant when someone estimates the number of hours a task will take — the actual total amount of time it takes to complete that task. This is focused, uninterrupted work without switching from one task to another, with everything needed to complete the task. So if a task took eight hours to complete, it took eight hours; it could have been done in a day or spread over a week, but the work performed to complete the task took eight hours.

If you want to use hours as your measurement for estimates, that’s completely fine. The key is to make sure that if you say “days” you meant “days,” and “hours” you meant “hours.” How you go about estimating based on hours is up to you as a team, but I’ll present a strategy you could use later on in this series.

‍

Story Points

Now on to the good stuff…story points.

‍

Consistently Inconsistent

Story points are subjective, vague, lack the certainty that hours have, and are rarely used outside of the world of product development (though you could make a case for them being used elsewhere, as I will show you later). They’re fine the way they are, but we need to clear the air about what they are, what we’re estimating, and how to use them. We will do that here and in part 3.

Story points often get confusing about what we are estimating, and how we create estimates using them. I don’t just mean a estimating a task, but what we are actually measuring. When I say something will take three hours, I am telling you the amount of time it will take; when I say something will take three story points…well if you haven’t defined it then you wouldn’t have a consistent answer.

So what do story points measure? You’ve probably heard “complexity” or “effort,” and I’m here to plant my flag and tell you that they measure effort. Not just that they measure effort, but in no conceivable way do they measure complexity, and I will back it up.

‍

Complexity vs. Effort

If I’ve turned your life upside down, affirmed your never-ending struggle, or sent you in a chaotic, downward spiral, then good; complexity and effort are not the same thing and should not be treated as such.

When we say something is complex, what are we saying? It’s difficult. Well, difficult for whom? Likely you, the one estimating. Perhaps it’s something easy for you, so you estimate the complexity lower. How does that work if you are measuring how much the team can accomplish? You’ll look at the complexity and not get an idea of the amount of tasks you can get done; all you’ll have done is measure how difficult the sprint was. The business, clients, and users aren’t concerned how complex something is for you or the team, they care how much work it takes to complete that task and when it will be done.

Even within the team, we know that some tasks are more difficult than others: throw a React engineer into a backend project using Python and you’ll learn quickly that code isn’t just code. Even developers within the same expertise have differing ideas of how complex something may be, and how easy or difficult it is to complete a given task. We acknowledge this when we use titles like “Junior Engineer,” “Senior Engineer,” and “Architect” to differentiate between the skill levels of developers. Is it not safe to say that — generally speaking — the senior engineer may know more than the junior, and the architect know more than the senior, and that they have differing levels of experience? What’s simple for an architect may leave the junior staring at their monitor in soul crushing despair.

These are important distinctions to make; complexity varies, but the work required remains the same. There certainly are complicated ways to print ‘Hello World,’ but how much work does it take? Well it depends on expectations set at the beginning of the project — in this case, in what language are you wanting to print ‘Hello World’ in? A project, and even a specific part of the project, can be complex, but the work around it remains the same regardless of the developer assigned to the task.

‍

Recap

We’ve confronted a lot of bad habits and rebuilt an understanding of estimation and how to use story points vs. hours. It’s a lot to take in, so I will summarize what we covered:

1. Story points are not hours
2. When using hours, it’s important to define whether you mean “days” or “total development time”
3. Story points are vague and lack certainty — leave them alone, they’re fine
4. Complexity and effort are not the same thing
5. Story points measure effort

I know this is a lot to process, and we still haven’t gotten to how to actually use story points yet — we will get to that in the next installment of this series. What we’ve done so far is break down why estimates are important to the team and business, as well as what we mean when we use different kinds of estimation. We’ve spent a lot of time laying the groundwork and framing this discussion to get you in the right mindset to use story points and why they aren’t as specific as hours.

Remember from Part 1: 90 percent of painting is prep.

‍