What are Story Points?

Howdy, Upstarts!

The terms Story Points is a piece of software development jargon that frequently surfaces in conversations about Agile Development, Agile SCRUM, or KANBAN Processes. If you have spent any time speaking with SCRUM masters or working with agile software development teams in the last 30 years, then I am sure that you have heard the term in at least one meeting. There are several different frameworks to manage software development teams; but, one of the Fundamental Concepts shared by all of these frameworks is Story Points.

I want to provide a common understanding of what Story Points are and why you should be using them to measure the performance of your software development teams.

Once we have a strong understanding of Story Points, we can talk about more advanced topics. There are several tips, tricks, and techniques to leverage Story Points to push your engineering organization to quickly build high-quality technology products.

… So, What are Story Points?

Story Points are a unit of measure for the level of effort, or the amount of work, that is necessary to complete a task.

That’s it! Pretty Simple!

So, when you are developing a new feature, features that have a higher Story Point Value are harder to finish, and so those features will take more work.

… So, Why Should I Measure Story Points?

By definition, every optimization problem begins with measurement. If you want to build a faster race car, then you need to be able to measure the car’s speed. If you want to build a more efficient process, then you need to be able to measure the process’s efficiency.

After all, you cannot build an Air Conditioner without building a thermometer!

If you want to improve the operational efficiency of your engineering organization (which you should!), then you need a way to measure that operational efficiency.

Story Points are how you optimize your engineering organization!

Story Points are the first step to measuring the operational efficiency of your engineering organization. If you track Story Points for your development teams, then you can tell how much work your team has completed. If you divide Story Points by rime, then you can tell how quickly your software development team can deploy new features. If you create histograms of Story Point values, then you can measure developer seniority. If you create track historical Story Point values, then you can identify source technical debt for your technology product.

By measuring Story Points correctly, you can do some pretty wild things and you will be able to optimize every single aspect of your engineering organization!

Story Points provide a measurement that engineering leaders can use to improve their development teams and CTOs should use to optimize their entire engineering organizations.

But why do development teams use Story Points, instead of just estimating how long a feature will take to complete?

Why do Story Points Exist?

If you have worked with a software development team before, then you know from personal experience that every conversation revolves around one question. There is always a lot of mention of things like bugs, integrations, servers, and what-not; but, the fundamental question that every software development team needs to be able to answer is:

When are you going to Launch that Feature?

Everything revolves around that question: hiring new employees, increasing your budget, or buying third-party tools. Every single aspect of software development boils down to answering the question of when the team will deploy.

But there are a lot of problems with providing a plain old time estimate. The biggest problem is that when you estimate development effort using time, you also need to account for the uncertainty of that estimation. For example, let’s say you commit to a feature being deployed in 80 hours; then, you would also need to estimate how much extra time you might need in case something went wrong. If one of your developers gets sick, would you need an additional 5 hours to complete the feature? Maybe 10 Hours?

Any time that you make an estimate, you also need to estimate the uncertainty; but, Story Points largely simplify this.

Story Points provide a short-hand measurement that incorporates complexity, risk, and uncertainty; and, a development team can use Story Points to estimate answers to this question without needing to explicitly account for complexity and risk.

It is important to understand that Story Points do not necessarily have a direct linear relationship to time; i.e. if a feature is assigned a value of 3 Story Points, that does not mean that the feature will need 3 days to complete. What is important to understand is that Story Points do correlate with the amount of time necessary to complete a feature; i.e. if one feature is assigned a value of 3 Story Points and a second feature is assigned a value of 5 Story Points, then the first feature will take less time to complete than the second feature.

I know that it is a bit fuzzy, and I am not a big fan of fuzzy measurements. I like concrete Data!

But, once you have accepted that Story Points are a measurement that aggregates several factors and that Story Points carry an inherent level of uncertainty, you can apply techniques to extract additional information from Story Points and to manage that uncertainty.

In the next articles, we will be discussing some of these techniques and how you can leverage Story Points as approximations for numerous other estimates.

In short, Story Points are a simple way to measure the level of effort which can then be used to provide time estimates that incorporate an inherent uncertainty and risk, allowing your software managers to avoid tracking uncertainty and to simplify the estimation process.

Although Imperfect, Story Points are a Useful Tool

In this article, I have explained that Story Points are the fundamental unit of measurement for development work, and you should be using this unit to optimize the efficiency of your engineering organization.

I have also provided a little background as to why software development teams prefer to work with Story Points instead of straight estimates of time, and why we need to understand that Story Points correlate to time, complexity, and uncertainty without necessarily having a direct linear relation to any one of those factors.

Once you have started tracking Story Points within your teams, you can use them to optimize several facets of your engineering organization.

In the next articles, I will be discussing some strategies for implementing Story Points and for using them to drive improvement for your startups.