It can be very interesting to write your user-stories in your backlog from SMART requests. They will make your job easier. So let’s see what a SMART request is in the world of agility.
SMART is an acronym that will give rules to create your functional requests that you can use to create your user-stories:
S => Specific: the request must be well defined and understandable by everyone who reads it.
M => Measurable: the request must be easily identifiable by the team so that the team knows concretely how it goes from “todo” to “done” without any difficulty.
A => Achievable: the request must be achievable by the teams without any doubt. The team must have all skills required to treat the request.
R => Relevant: the request must be relevant for the product and bring value to it. Why create a user-story if it adds nothing to the product and key users?
T => Timebox: the request must be estimable in time or estimable in its complexity. It should not have too uncertainties for the developers.
From request to user-story
If your initial requests are SMART (from customers or the Product Owner itself), it will be much easier to turn them into user-stories.
In some projects, it is not a mandatory to have user stories because you can not have all SMART criterias.
In Extreme Programming, we will focus on refactoring; Clearly, a refactoring request will not bring anything to a user but will be essential for code quality. In this case, we will not do a user story but a refactoring task because the request is not SMART.
I advice you to force the SMART concept on the requests that become user-stories because it brings quality assurance in the construction of your backlog.
Now you will know how to impose the SMART standard on the demands of future users of complementary quality in your backlog.