Constraints - when user stories don't do it for you

In "agile projects" it is common to use user stories to describe what has to be done. But it is also common to use constraints to describe things that cannot be described in a user story. This can be things like:

• Response times should always be less than one second.
• We should always apply coding standards in document XXX.

Constraints are things that should always be considered during every user story implemented.

However sometimes people come along with things that sound like constraints but they're not. For example:

• We should spend up to 10% of the velocity on improving performance.

This is a bad constraints since it have no goal. You might think you improve the constraint if you say:

• We should spend up to 10% of the velocity on improving performance until all response times are less than one second.

This is still a bad constraint since you probably have a release date. What happens if the constrained time is not enough to achieve the goal?

I think that if there is a known problem (for example some responses take more than one second) you should add user stories (or bugs) for that and prioritize and plan the fixes for those problems just like anything else. And if you have no known problems you should just set up constraints telling the team what kind of quality you want. If it takes the team 50% of the velocity to pass all the constraints you should let them do so since otherwise you'll have to let them do it later anyway. Either way you'll notice the team are struggling to pass all the constraints and maybe they are to strict. But if you time box them from the start you will notice this later than if you force the team to always deliver more or less release quality.