[sumtechguy]

They are good for 'hey can I get this crap done in a sprint'. Once someone starts measuring it for 'how good a team is' that is when it falls apart.

One teams points almost always do not equal another teams points either.

Agile has a TON of anti-patterns that look good to do and are enticing to do. But in the end are self destructive. Usually making it about the process instead of 'I have X amount of work and Y number of people how much can I get done in Z time'.

For example velocity. I measure it so I do not overcommit. Trying to do 50 points when 20 is the norm and something will happen that we do not want. But now that you have a measurable number some manager will want to brag on it (that is their job to brag about you). In the end being put on some spreadsheet to be presented to some other manager. It becomes a score to measure you against other teams and an anti-pattern. As actually testing if something is being productive is hard. But numbers you can get all sorts of them out of agile, leading straight to anti-patterns.

[lsaferite]

Story Points are inherently team specific as is Velocity. Trying to normalize them across an org for the purposes of a performance metric is folly. Velocity should be used internally on the team when doing timeline estimations, but exposing that outside the team is, again, folly. Even on a singular team, SP and V are subject to small drift or large corrections based on team makeup, time of year, or numerous other metrics. They are simply a planning estimation tool. As others have pointed out, the act of assigning SPs is a useful tool itself as it requires a team to collaboratively estimate complexity and it frequently helps surface miscommunication and missing details.