Our software development team is hitting their weekly target of story points delivered, but our product releases are full of bugs and our QA team is constantly overwhelmed with rework. How do we restructure our Scorecard metrics to stop our developers from gaming their productivity numbers at the expense of our software stability?

Question

Tyler Smith · Accepted Answer

When employees game their Scorecard numbers, it is a sign that your metrics are too one-dimensional. In software development, measuring only story points delivered encourages developers to push buggy code through the system to hit their target, shifting the burden and stress to your QA team.

To stop this behavior, you must introduce a counter-balancing metric that measures quality alongside volume. On your weekly Scorecard, pair "Story Points Delivered" with "First-Time QA Pass Rate." Both of these numbers must be owned by the development lead on your Accountability Chart.

Under the GWC framework, the development lead must understand, want, and have the capacity to deliver both speed and quality. If they hit their story points but their pass rate drops below ninety percent, their overall performance is still considered red. This dual-metric structure forces the team to balance speed with precision because they can no longer look good on paper while passing broken work downstream.

By structuring your Scorecard this way, you make it impossible to game the system. The data will reflect the true health of your operations. If they try to slow down too much to keep quality high, their volume metric goes red. They are forced to improve their actual processes and coding standards to keep both metrics green, which is the ultimate goal of running your business on data.