On what scale do you measure your planning?

Hi product people! I’ve noticed a trend with my team when estimating stories (we use a Fibonacci pointing system) that they’ve started rating almost everything a 3 during the planning poker phase. When talking with my manager, we think that its due to some worry in the team that they’ll be seen as “wrong” or “way off” because I usually request some sort of explanation for any deviation from the norm so that we can make sure we’re not missing anything. Looking really for two things:

  1. Does anyone have a good resource on what a “1” vs a “2" vs …etc. means? I’m hoping resetting the scale with the team will help partially
  2. How do I combat this fear their estimates not matching their teammates?
  1. Unfortunately, story points are (intentionally) highly subjective and team specific. They are meant to be relative. If you’d like to reaffirm sizing for your team, you may want to try the Team Estimation Game with stories you have already done to see what your team would size stories with perfect knowledge.
  2. Instead of asking for explanation for “deviation from the norm” instead ask what did we learn from this story that we should consider with other similar stories. (if it turned out be a significantly different size than you thought)

Thanks @NathanEndicott, I guess “being wrong” is probably the wrong term, its more the fear that their estimate wont line up with other developers, not so much that it will not match the “actual points” that we could determine after the work was completed.


If the team is sizing items as a team, the size not lining up with others should be a moot point.


Also — is there actually a problem? Folk getting good at breaking down work into chunks of about the same size is a skill I see good teams developing over time.
If there is a problem — is it coming up in retros? If it is coming up in retros how are the teams addressing it?


@Felipe, Interesting take, to be honest, now that you mention it, points don’t really come up in retros, and rarely after the sizing convo, its more of a managing up tool to guess at how long a project will take and communicate that to the stakeholders. So from the dev’s point of view, there’s no downside to guessing a 3 even if they may actually think its a 1 or a 5, because I don’t really bring it up to them again. but if they guess a 5 and someone else guesses a 1 they might feel dumb that a task might be so much harder to them than their coworker


That sounds like a trust & safety issue. If people don’t feel safe from expressing their opinion of of being wrong, that’s a bigger issue than assigning an ‘incorrect’ story point. In my opinion, I care less about the actual story points than I do about the conversation that’s generated when people initially disagree with each other. If one person gives a 1 and another gives a 5 or 8, that’s when there’s an opportunity for the underlying assumptions to be brought to light. If I were in your shoes, I’d try to address the cause of your folks not feeling safe to bring up dissenting opinions.

One possibility is to assign a court jester. That’s a person who is designated to go against the grain. See if that opens up more conversation. Just a thought.


I could be projecting on my last point, I did bring it up with the team, and another factor that came up was that there was a big gap between what they consider a 2 - “add a label and update small action” and a 5 - “create a normal feature”


Given that gap in definition and the fact that a 3 is the thing in between it seems as though @FelipeRibeiro may have hit the nail on the head that there may not be a problem and that the team has gotten good and getting things to all about the same size.


One thing that helped one of my teams figure out differences in pointing (everything was a 5) was to look at it in “buckets.” If it’s slightly larger than a 5, it’s not a 5, it’s an 8. If it’s slightly smaller than a 5, it’s still a 5 because it’s “too big” to fit inside a 3 bucket.
It’s a very small thing, but it helped them think less about rounding to a point and therefore everything getting the same point.
As @FelipeRibeiro mentioned, we got to a good place where things were consistently split. The only problem was that we would miss sprints because some 5’s were bigger than others and we forgot that during planning.


As @Michael mentioned, it can be a trust issue… try to look for other places where the communication is also a bit strange.

Regarding options for the sizing, try to use the retro. Pick a size 3 story that was faster/slower than expected and ask what they can learn from it.
What we can also do is, during the sizing, pick two stories with size 3 (that you feel have different complexity) and ask them to compare. Sizes are supposed to be relative.

1 Like

May I ask, how are the story points and estimations used outside your team? If all items are roughly the same size, there shouldn’t be much variability as to how much time it takes to deliver them (i.e. cycle times). Is this your case?