So what is a check-in policy?
If you're reading this blog, you're probably familiar with Team System check-in policies; we have three out-of-the-box—code analysis, testing policy, and associated work items. You can apply one or more—or none for that matter. If your pending checkin fails to satisfy all the policy conditions, your checkin is blocked until you satisfy all the conditions.
Most people I talk to think of policies as a tool for preventing problems from happening. Consequently, they're bothered by the ability to override a policy.
However, there is another way to think of a policy—as a caution light. For example, when the "check engine" light lights up in your car, it's usually a good idea to take your car to a mechanic as soon as possible. However, sometimes that indicator might be wrong and you both know that it's a false indicator and why it's a false indicator. When that's the case, you should have a way to ignore (override) that caution. Just to make sure people don't use this as an excuse to ignore valid policies, TFS tracks any policy override. If you want to know when they happen, there is a tool just for that: Policy Override Notification Tool (external—not supported by Microsoft). Also, Darren Jefford blogged about setting this up in a more "official" fashion with the bisSubscribe tool here: Team Foundation Server: Subscribing to Policy Overriden Events on Checkin.