How to Help New Developers Understand Story Points Without Confusing Them?

Honestly, I think dropping story points entirely might be helpful. Transitioning to a Kanban system can take away much of the overhead and complexity associated with story points, making it easier for juniors to adapt without the additional confusion of trying to estimate based on that scale.

I agree with starting off simple. One effective method I’ve seen is using a comparison matrix that considers task complexity alongside effort, risk, and scope. It helps everyone understand that a task isn't just about how long it might take, but involves various factors. This dual approach allows for clearer communication within the team and better calibrates estimates over time.

It's important to explain that story points are a measure of complexity and not time. Once you introduce the concept of hours, it muddies the understanding because people often underestimate how long tasks actually take. Keeping story points abstract allows the team to focus on relative sizing instead of precise hours where individual speed varies too much. It's also helpful to establish benchmarks, like showing examples of typical tasks that fit into the 1, 3, 5-point range. This can help new devs get a better grasp of what those numbers mean.

Here’s the thing—story points are not estimates of time; it’s more about perceived effort and how complex a task is going to be. Try not to mix in a time frame, and focus on questions that prompt discussion about risk, familiarity with the tech, or potential unknowns in the task. This way, new developers don’t tie story points to hours directly.

Just stick with relative sizing. I suggest using past stories as reference points for new work. Instead of throwing out velocity data immediately, focus on helping them understand that estimating is about comparing the new work to tickets with known story points. For instance, if they rate a new task as being similar in complexity to a task previously rated as 3 points, they should feel comfortable estimating it the same way. This approach avoids introducing confusion with hours too soon.