Story Pointing Basics
Alright, let’s take a look now at story pointing what are story points. Chances are you’ve heard a lot about story points, so let’s get to the bottom of exactly what they are and how they are used. Story points are used by teams to reflect the complexity or difficulty of a user story, and they’re based on relative sizing.
OK, well, what does relative sizing mean? I happen to not be very good at judging how tall people are. If you ask me, “How tall is Bob?” I would be hard-pressed to determine if he’s 5′ 9″ or 6 feet tall. However, if you ask me, is Steve taller or shorter than Bob? I am far more likely to get it right. So relative sizing, in this case, is comparing something new, Steve, or a new story or unit of work to something known, Bob, or an old story or completed unit of work.
Let's take a Closer look at Story Points
Let’s say that Bob is a relatively complex user story, while Steve is less complex and will be easier to deliver. Let’s point Bob at a 5. And Steve is not quite half as tall or difficult, so he gets a story point value of 3.
This pointing is done as teams commit to delivering the work in their backlog. This is often done in a quick round of planning poker, where team members all make up their minds about the difficulty and complexity of the user story on their own, and they show their cards or share their story point values all at once. Much like the showdown in a hand of poker. If one team member has a wildly different point value for a story that warrants a conversation.
If there is a wide gap, in other words, in how one team member points or views the complexity of a user story and the way another member sees that difficulty, maybe the rest of the team is missing something. Like the fact that external skills will be required to complete this story or that there is an impediment to completing the work that no one else has thought of.

Tips for Agile Teams Working Remotely
Story Pointing and Benchmark Stories
Each team selects a baseline or benchmark story to compare every other story in their backlog to. Remember how we were able to determine the size of Bob and Steve. We started with Bob being in our backlog and a known quantity, and we knew Steve was smaller than Bob.
Ideally, this benchmark story is a very small task that can be completed, tested and accepted within one to two days. This benchmark story should be pointed at a three or five on the Fibbonaci scale.
OK, what’s the Fibbonaci scale? The Fibbonaci scale or Fibbonaci sequence is just a sequence of numbers. It happens to be very interesting, and if you’ve got some time, Google it. The math behind the Fibbonaci sequence and the Golden section and Golden ratio and all the opportunities this happens to present in nature… It’s pretty amazing. But for our purposes all we need to know is that these are numbers that when the two previous numbers are added together, they result in the next number. So for example, if you start with 0 and 1 and you add those two numbers together, you get 1. If you add 1 and 1 together, you get 2, 2 and 1 is 3, 3 and 2 is 5 and so forth.
Most companies do encourage teams to further refine any story that’s larger than an 8, or maybe a 13 on this scale. Keeping those story values small. So that’s where the numbers for the points come from. But the big point here is that all future stories are pointed by comparing them to this benchmark story, just like we compared Steve to our benchmark of Bob. And another thing to consider is that each team’s benchmark story will be very different.
They can be completely. Different, just like you might be in a room with much taller people than I am. Maybe you’re at a basketball team practice and everyone there starts at 6 foot 3, whereas I happen to be in a room full of normal size people. So your benchmark story, your Bob, is going to be a lot taller and difficult and more complex than mine, so there’s no value in comparing Story points from one team to another.