Velocity Dampeners > Agile Scrum Sizing
One of the biggest weaknesses of agile scrum is that complexity isn't uncovered in the sizing process but by actually doing the work. While sizing is useful in uncovering assumptions about a feature, it's not great at uncovering dark patterns from a technical perspective.
So, what's the solution? Focusing purely on velocity! By focusing on decelerators rather than points, you're focusing on the things that are actually slowing down your team's velocity versus an always optimistic or inaccurate estimation of a feature.
Instead of structuring the retro with what shipped, what didn't, and how do we improve, try focusing on a single prompt which is: what's slowing our velocity? This can uncover a lot of the dark patterns that inhibit a healthy software development lifecycle.
For example, something as mundane as spending a lot of time trying to find something because the internal documentation sucks or not having access to x, y, or z can slow down the velocity of your team.
If you want to evaluate the team's performance, just time how long it takes from start to finish for a ticket to close. This can help you understand your individual contributor's productivity, your team's productivity, and give you a better sense of when your team will actually ship.
Remember, focusing on velocity over points can uncover a lot of the dark patterns that inhibit a healthy software development lifecycle.