As I discussed in another post, features are a great opportunity to motivate the team but are, instead, often written with wordy but shallow descriptions of desired functionality. In fact, it's worse. Most feature tickets are complete crap. After removing the wordy and shallow description, nothing is left. There is no concrete, actionable functionality to implement, just a vague notion of an idea.
Vague notions create confusion, which drains morale and destroys productivity. Product managers exist to eliminate the confusion that inherently will exist between multiple stakeholders who have different priorities.
Robust feature tickets provide the team with six, confusion-eliminating statements.
The new functionality should be explicit. Most tickets go off course right at the start, providing an abstract goal. The ticket will say something like, "this feature is to improve the customer registration process because it is too confusing."
Really, just stab me in the eye with a pencil.
Instead, "We are going to remove the customer address form from the registration page."
The problem solved by the feature should also be separately stated and explicit and should provide reference metrics whenever possible. Building on the prior example, "Our marketing funnel currently results in 1% conversion to registered trial users, and 50% of the users that start the registration process do not complete it."
The value provided by a feature is frequently given by subjective terms with statements like "this will be better." Better how? Value can always be estimated, and the estimated value of the feature should always be provided along with the methodology used to create the estimate. If a value can't be assigned to a feature, it shouldn't become a priority until it can.
The technical context explains how the feature will fit into the current environment and delineates the technical scope of the feature. Continuing with the current example, if the address is removed from registration, where will the system collect it going forward? Or, are there any components that depend on the registration address? Will these issues be resolved in this feature or other features?
Acceptance criteria should enable QA to verify that the feature is complete. If someone else needs to review a feature after QA, then the acceptance criteria are inadequate. If the QA process is flawed, that's a separate problem.
Finally, the feature should have success metrics that will be used to evaluate whether the goals of the feature were achieved. After all, if the organization doesn't care whether or not a feature is successful, why should any individual care?