Story points are assigned to each user story to estimate how much work a development team can complete in a Sprint. So, why not just assign hours instead? Because, every team member, depending upon their expertise, may have a different view on how many hours a particular story may take to complete. However, asking the team to categorize user stories based on stories’ relative difficulty to each other is easier, and more realistic way to estimate work.
There are multiple ways to assign story points. Here’s how I do it:
(1) Pick a user story: Ask the team to pick what looks like an average sized story (E.g., building a user login page) and stick it around the upper middle part of the whiteboard so we have enough room on both left and right to form new columns. Many people also choose to use Excel or some other digital tools to accomplish this, especially in a remote work environment.
So, how do we know that the user story we picked is of an average size when we’re doing this exercise for the very first Sprint? The realistic answer is, we don’t. It’s just an instinct based on prior experiences. By the time we’re done sizing up stories, the first story we picked may very well end up being of a smaller or larger effort than we initially thought.
(2) Sort stories by difficulty: Now that we have one user story up on the board as a reference, sizing rest of the stories based on their relative difficulty to each other becomes easier. When we’re done, all stories should be sorted into columns and our board should look something like the following.
(3) Assign sizes: Now, name each column using the T-shirt sizes – XXS, XS, S, M, L, and XL. Any story that goes beyond the XL scale is probably too big. Break it down to smaller chunks. Now, our board should look like the following.
(4) Assign story points: Finally, it’s time to assign story points to each category. I recommend using one of the popular methods which is the Fibonacci sequence. It is a series of numbers, each the sum of previous two numbers. Now, our board looks like the following.
(5) Finalize the Sprint Backlog: Now that we’re done with the sizing part, it’s time to figure out how many stories the development team can take on in the upcoming Sprint. If this is our first Sprint, there’s no empirical data on which to base our estimate. So, trust our intuition and roll with it. Let’s say the team takes on two large (16 points), two medium (10 points), and three small stories (9 points), totaling 35 story points. But they end up accomplishing 29 story points worth of work in the Sprint. Now, we have our first data point to understand the velocity of the team so we can adjust the amount of work for the subsequent Sprint.
After two or three Sprints, the velocity becomes clearer, allowing the team to pick the right amount of work (measured in story points) more consistently, and helping the management forecast the project timeline and budget with better precision.