Should individual ability be considered in story points?

Question

My understanding of story estimation has been that one should estimate the size of a story as it would be for an imaginary, average developer — a bit like the "reasonable bystander" concept in law. That is, you should not estimate the story's size assuming you have to do it.

To give an example: in my previous job I was part of a team where I was far and away the most confident Ruby developer. My teammates would routinely estimate Ruby-related stories far bigger than I would, with arguments like, "Well I don't know how X works in Ruby, so this would take me ages to do."

My argument against this comes from the fact that sprint planning is where the team's capacity comes into play. That is the correct forum to say, "Our capacity this sprint will be slightly lower than usual because the majority of the tasks are Ruby-based, and we only have one strong Ruby developer." Factoring this in during estimation would double up this aspect.

I'd appreciate any authoritative references in answers, but simple opinions would be great too.

Answer 1

Story points are a relative estimation. So twice the points means twice the level of effort. Relative estimates are less subject to skill level variations. The question is not so much how much time you would take for 1 point, but that 2 points require 2 times more potential effort. Skill level could matter more if you would take ideal days instead of story points, because you assume an individual productivity level.

Relative estimates are more robust. In addition, the story point evaluation should not be performed by an individual, but result from a collective team effort. For less complex stories, there's usually a quick agreement. For more challenging stories, the team will come with a result to which most of the members will agree, and therefore implicitly take into account the collective skill level of the team.

Finally, story evaluation is performed at a moment when assignments within the team are not necessarily already decided. This is one more argument not to take into account individual skill level. For sprint planning, you'll take the story point capacity of the team, which is a figure that will evolve based on actual performance figures, so that it will self-adjust to the global skill level of your team.

In conclusion, the individual ability should not be taken into account for the estimate. But even if it would be done, due to the collective estimates, and the robustness of the relative approach, it wouldn't matter so much.

Answer 2

The canonical answer is that you shouldn't change the estimates per developer. That would mean that you get tons more points done per sprint than your peers, and that's fine because points measure the team's velocity, not developers. Business can estimate how much the team will produce to get rough expectations of delivery, and everything is great.

Yet that causes all sorts of trouble in practice. What happens if you're on vacation that week? What happens when review time comes around and you realize you're producing 200% the average story points for 110% the average salary? What happens when business starts thinking that team velocity divided by people is actually an accurate approximation? What happens when business realizes you're producing way more bugs than your peers (while ignoring you produce way more functionality)? What constitutes "bite sized" stories when people have such varied bites?

What I have found through my career is that it largely doesn't matter. Process is there to serve you, not vice versa. If your org needs to gauge if devs are overloaded, then per-dev story points are a good solution. If your org needs to gauge team velocity, then dev-agnostic story points will provide a clearer picture. Yet they're always an approximation, and always going to be abused and misinterpreted.

In the end, they're made up points for a made up process that you need to adapt to your environment.

Answer 3

TL;DR
We should always assume that only competent developers will be assigned to a particular story.

Competency (or lack thereof) is not an insult. It is simply a reasonable measure of the skills of a developer who is neither lagging behind nor exceptionally experienced.

---

This can be a matter of a particular company's approach. I've seen companies tailor estimates to particular developers. I've also seen companies who enforced a system where three randomly selected developers make story estimates before almost randomly assigning a developer (not one of the initial three) to the task.

Every system can work, every system can fail. The question isn't so much which system is better, but rather which flaws the company is able/willing to deal with.

---

In principle, study time for mastering the language/framework should not be included. Minor tangent: although they shouldn't exist in an ideal world, study time for project- or story-specific obstacles should be included.

There are many justifications for doing so, but I believe this approach is generally a better choice, because it stays true to the intention of estimating a workload. This might just be a matter of my opinion, rather than objectivity. I can't say for sure.

Study time is personal. It is in scope for a particular developer who needs to work on a particular technology. It is not relevant when assessing the workload of a user story, as a user story is only in scope of the application (and the technology it uses).

Study time generally does not stack. Let's say that our rookie knows little of C#, and we estimate that he needs three extra days to figure out the environment before he can do the work. As is common in many companies I've worked in, we're now in a meeting where we are expected to estimate several user stories (individually). For the sake of example, let's say we have three stories to tackle.

• Do we add three days to each story? If all three stories have a similar technical focus, that means that the rookie won't actually need the extra time on the second and third story. We've overestimated the work by six days.
• Do we add one day to each story? This isn't correct either. If we only end up assigning the rookie to one of three stories, then we've shortchanged him two needed days of studying time; and we've given two unnecessary days of study time to other developer(s).
• Do we add three days to one story? How can we guarantuee that this story will be handled before the other two? The whole point of creating separate user stories is that the stories can usually be tackled independently of one another. The correctness of our estimate now hinges on both the assumption that our rookie will do the work, plus the order in which he is assigned those tasks (if it matters, e.g. if the combined workload surpasses a single sprint).

Note:
There are other cases where study time does stack, e.g. if the three stories are on wildly different topics and require different skills.
But to find out whether this is the case or not, we would need to look at all three stories at the same time, which slowly starts violating the principle of having independent user stories. If we had tackled these estimates in separate meetings, possibly with different developers present; we would be unable to accurately gauge the overlap between the stories.

Because we cannot guarantee which stories will actually end up being done (the customer might refuse a large estimate), and who will be assigned to them, trying to account for a particular developer to be assigned to a particular story is futile. It only ends up muddying the water.

Instead, we should render an estimate of the workload assuming the rookie has already been brought up to speed (and is therefore an equal developer to his coworkers).
Such an estimate is developer-agnostic, and the correctness of the estimate therefore doesn't fluctuate depending on which developer ends up being assigned to the story.

Note
It's still relevant to acknowledge that a particular developer may need extra time to study before being able to tackle a particular story. That is still a very relevant consideration. But this consideration should not be attached to the story, but rather the assignment of this particular developer to this particular story.

---

But, as I started off with, this can vary from company to company. Some companies might not be all that fussed about study time (e.g. if the developer will inevitably have to learn to use the technology anyway). Others might heavily rely on the accuracy of these estimates, as it influences billing to a customer.

In the end, it's a matter of picking your poison. None of these approaches are guaranteed to be more accurate than the others.

Answer 4

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.

1. 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?

2. 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.

3. Story-Pointing by consensus: Applying Volume, Unknowns, Complexity, Knowledge

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.

4. 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.

Answer 5

TLDR

No, but perhaps not for the reason you think.

Long Version

Many of the other answers have explained that Story Points should be calculated purely in relation to other pieces of work. This is absolutely true. As Story Points estimate the amount of work rather than the time required to complete it then it makes little sense to give Story Points based on an individual.

For example (one of my favourites), consider your task "Dig a hole". You can either estimate this based on the amount of earth to be removed or the time it will take you to remove the earth. My friend digs a whole at a rate of 3 metres per hour, I have a large mechanical digger so I can manage 100! The only constant is the amount of earth - therefore that's what we use as our unit of estimation.

However, a second (and in my view more important) reason for discounting developer ability for estimating user stories is the fact that almost every user story will likely be worked on by multiple people.

You may have an architect, a developer, a tester, perhaps a second developer to do the UI. Before your user story is marked as Done (ideally deployed and done) many different people will have worked on it. Suddenly the idea of estimating based on the developer in question makes very little sense, the only way to accurately estimate how much effort will be involved from the team is to measure the teams' velocity and estimate work for the team to complete.

There is no "I" in team and absolutely no I in agile planning!