How to Help New Developers Understand Story Points Without Confusing Them?
Asked by
TechWanderer42
I'm currently onboarding some junior developers, and they keep trying to correlate story points with hours, asking things like how many hours equal 5 points. It seems they're missing the bigger picture. I usually begin with using t-shirt sizes (S, M, L) and then introduce the Fibonacci sequence for estimating, but I'd love to hear what has worked for others. Should I present them with historical velocity data right off the bat, or keep it more abstract initially? Also, I'm facing some challenges in getting them to consider both complexity and effort in their estimates. Any effective frameworks or analogies you guys have used that really clicked with your teams?
Answers
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.
Reply to this answer
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.
Reply to this answer
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.
Reply to this answer
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.
Reply to this answer
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.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions