How to effectively assign points to scrum stories

One of the more interesting aspects of scrum is the ability to assign points to stories. The problem is, finding much useful information about this idea is quite challenging. First, what are story points? Next, how do you effectively assign points when they seem rather arbitrary? I want to try to help you make sense of this. In the end, what we come up with might not be an official definition and explanation, but it’ll certainly help you better understand how to use this feature in your team’s scrum system.

SEE: Business leaders as developer: The rise of no-code and low-code software (free PDF) (TechRepublic)

What is a story point?

In simplest terms, a story point is a value attached to an effort for completing a task. It’s like rewarding effort with a grade, only instead of A-F, it’s maybe 1-5. You completed a challenging task, you get a 5. Complete a simple task, you get a 1. 

But what do these points mean? I see two ways to look at story points. The first way is kind of the official take, which makes it possible to estimate backlog in terms of effort (instead of hours). Many teams find this less daunting. On top of which, it’s considerably easier to assign a level of difficulty to a task than it is to assign the number of hours a task will take. And this is at the heart of scrum. Why? Because change happens.

You might think you know exactly how long it will take to finish Task A, but things change and hurdles are constantly thrown in your way. You might have been assigned 20 hours to complete task A, but in reality, it might take 30 or 40. On the other hand, you are better equipped to know how difficult Task A will be to complete. 

In the end, a team can look at several tasks they’ve been assigned and see that the total effort involved will be, say, 40. If there are only eight tasks involved, they can be assured that challenge awaits them and they’d better have their A-game at the ready.

It’s confusing. But remember, this isn’t just about complexity, but about effort. For example, the README file. These aren’t particularly complex but can involve a lot of writing and collaboration. That might take considerable effort. So, even though the README isn’t complex, it’s time-consuming, so it might be assigned 5 story points.

But let’s consider another reason to use story points … a reason you won’t find them written about often.

Competition.

Let’s face it, developers are just as competitive as other employees (maybe more so). Developers like to brag about their accomplishments (and rightly so; developing is be a very challenging profession).

Although story points were never intended as a measure of success, they can certainly be used as such. At the end of a sprint, how many story points has each team collected? You see where I’m going with this.

The team with the most story points could certainly be rewarded. After all, a bit of competition is a great incentive. Even if there aren’t actual rewards, the bragging rights alone are worth implementing story points.

Of course, this isn’t the popular (or accepted) use of story points, but let’s face it … it’s valid. 

How to assign story points

This is where it gets a bit cloudy. Truth be told, it’s all pretty arbitrary. How many points is a task worth? Do you know? Is there an official system of measurement? There is not.

Say you have Task A which is relatively easy, such as generating an initial commit. On a scale of 1-5 (1 being easiest, and 5 being most difficult), that task is probably a 1. Every developer should be able to do an initial commit in their sleep. And what about that README we talked about earlier? It could be as simple as copying and pasting from a boilerplate (story point 1), or it could require a good deal of original content, some research and collaboration (story point 3).

Of course, there’s no reason story points have to be limited to 1-5. Depending on how much work you want to put into it, you could have story points from 1 to 50. Here’s what I suggest you do. First, create baselines for each story point. Let’s go back to the README file. Let’s stick with the simplistic 1-5 scale. Say all of your READMEs are pretty simple, requiring not much more than licensing information, contact information, and a description of the project. That’s a 1.

SEE: Top keyboard shortcuts you need to know (free PDF) (TechRepublic)

Next is writing code. Maybe one programming task only requires a developer to toss in a few functions from a library. That’s a 2 because it’s pretty cut and dry. But what if you have a task that’s all original code, but not so complex that it’ll seriously challenge a developer. You have yourself a 3. 

What about a piece of code that’s a combination of original and some pre-built code from libraries and frameworks? Give that a 4. Finally, you have a level-5 story point assigned to the most challenging tasks that might require writing new functions.

Then, of course, there’s building (maybe 3), testing (possibly 5, because testing can take considerable effort) and deploying (probably a 2 or 3).

Granted, I’m just randomly assigning numbers to these tasks, but you get the idea. 

Another popular method of assigning story points is using a Fibonacci sequence. So, instead of numbers incrementing by one, they rise according to the Fibonacci sequence (the sum of the previous two numbers), as in 0, 1, 1, 2, 3, 5, 8, 13, 21, etc. With such a sequence, you could more easily assign story points to tasks. For example:

• Add a product to a drop-down menu is 1 story point.
• Add a new animation to the drop-down menu is 2 story points.
• Add a rating system is 3 story points.
• Add order tracking for users is 5 story points.
• Add two-factor authentication for user logins is 8 story points.

What’s important about the assigning of story points is that you be consistent. If these points seem random, they won’t really be fair. To that end, develop a baseline so you not only avoid arbitrary numbers, but it can become much easier to assign story points.

And there you have it … my take on scrum story points. Your business probably has a completely different take on how this feature works, but it’s always good to consider other ideas. Regardless of how you use and assign story points, just make sure you are consistent.

Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.

Developer Essentials Newsletter

From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know.
Weekly

Sign up today

Also see