This is a complex topic, and there are frequent debates on the topic. I do not like the concept of "canonical" opinion on this: there are various opinions with value. But there are supporting values, principles and practices that should guide the approach.
The following is based on my own opinions working with scrum teams for over 10 years. But it just MY opinion.
Story Points as a Forecasting method
The original intent of story points was to find a quick method to estimate effort with the purpose of forecasting what a team can complete during a period of time. Some of the "luminaries" state that points are used only to forecast longer-term scope (over a release, for example), and not to determine capacity at the sprint level.
Additionally, the concept is that teams are applying "relative sizing" based on historical values (Effort X is similar to Effort B, which was 3 points). This speeds up the estimating process so teams don't have to break down future work into detailed work packages and apply hours to all the tasks.
High performing teams strive to grow all technical workers into very competent members of similar skill levels. (This concept will be explored more in point #4) When this is achieved, then individual skill level is really not a variable in sizing. BUT: It usually takes quite a long time and concerted effort to achieve that goal. SO...what do we do before we get there?
Task hours determine sprint capacity: According to the same "luminaries" who state that points are used for long-term forecasting, they also propose that Task Hours be used to determine sprint capacity, rather than points. In my opinion, that is fine, but I will say that when I have helped coach teams to "High-Performance", their leveled-out skills averaged out to where they could accurately determine what they could complete in a sprint using Story Points only. Again, that can be an objective toward which we strive, but newer teams are not ready for that.
Therefore, you may find in a single sprint a Story with 2 points that has 12 task hours of effort, and another with 25 hours of effort.
So what do you do?
Some folks that I call "agile-purists" will state that Story size (in points) should be agnostic to duration. Others disagree.
Read through the logic on item #3 and see what you think.
- Story-Pointing by consensus: Applying Volume, Unknowns, Complexity,
So teams look at a piece of work and need to agree on the points which will be a proxy for Level of Effort. Right?
Assuming that all skills are equal, then consensus is easy to reach. But often teams have a guy who is a Java guru, another who is not so great in Java (maybe she was a C# or .Net or Cobol person and is learning Java). So task X for Bob is very simple. For Jane, it is more difficult.
Agile teams try to promote collective code ownership, and growing/expanding expertise. So we don't usually assign stories to people based on their expertise: we prefer teams collectively work on stories and learn together.
This aligns with the concept of "slow down to speed up": if we take the time to give Jane experience with Java, while this may slow us down at first, later we will have more competent Java developers. In fact, if we have only ONE Java expert, and everyone works on their own areas of expertise, we are creating a situation with multiple potential "points of failure". What happens in the sprint when 90% of the work is Java, but Bob (our Java expert) is sick or on vacation? By expanding skills, we eliminate potential bottlenecks and reduce risk.
With that in mind: When the team looks at a story they should have several concepts in mind when sizing. You can think of the acronym VUCK to remember this.
Volume: Some efforts are quite simple, but require a great volume of repeated tasks. (I had a guy who had to copy and reformat 50+ tables who said it was 1 point because it was simple. But upon reflection the team realized that while it was easy, it was time consuming and there was a large volume of tables to be moved and optimized. So we had to readjust points due to the volume of work)
Unknowns: Sometimes we THINK we know what to do, but we also identify some unknowns--these represent RISKS. And this implies that we may run into unexpected issues we have to resolve, redesign, or try a different solution.
Complexity: This one is pretty obvious. Some solutions are technically complex. We know exactly what to do, but it requires technical expertise. Complexity also implies some risk, doesn't it? So even if we all have equal skills, the technical complexity implies we might run into unforeseen challenges. So we might make this story bigger.
Knowledge: Do we REALLY know what we are solving? Sometimes customers are not entirely clear on the solution they want, and we are experimenting a bit. Or perhaps no one has ever implemented this solution (new technology never used before) and so we don't know what we don't know.
In my opinion, every one of these considerations is actually a proxy for extended duration. Easy story, lots of volume? It will take longer, or we need to split the story. Unknowns? Added risk, research, experimentation, it may take longer or we need to split the story. Complex? Added risk, need to fix bugs, redesign etc. so it may take longer. Don't know if we have the required Knowledge? We have additional risk, may need to experiment, etc, so it may take longer...
See where this is going? So while the concept of story points discourages us from thinking about duration when estimating, on the other hand it would be illogical to have a 1-point story that we can complete in 4 hours and another 1-point story that is simple but will take 2 weeks.
- High-performing teams eliminate Silos & Bottlenecks: Because teams try to level up all of the members, they sometimes have less-experienced members take on new challenges, or will pair-code to share knowledge in order to improve as a team. As previously mentioned, this is a requisite if the team will ever reach true High Performing levels.
So if Jane volunteers to take on that Java effort and that would make the effort 2x or 3x the duration of the same effort if Bob were to do it, what do you do?
Over time, my teams settled on sizing stories based on the level of effort (LOE) / VUCK for the people working the effort. It makes no sense for Bob, the team Guru, to say "that's a 1" when for Jane it will not be easy and take a week to complete, plus require some of Bob's time for pair coding and code review. Therefore, we bumped up those points to reflect the real LOE.
The next time a similar story came, what was an 8 for Jane previously became a 5. Eventually, everyone agreed it was an easy 3.
At that point, we knew we were growing as a team.