A User Story should be formulated using the following pattern:
"As a <user>, I want <requirement>, because <reason>."
This can be also reflected in the Feature ticket, mostly.
E.g., or the Feature "Presentation of MRO objects on the client"For most features, we need to do different kinds of things, i.e., customize several steps:* Find out the ACM, customize the client UI, import work packages from requirements* Make a 3rd party system, etc. For all of those task groups, functional design (FD)* Make a User Story can be created to encapsulate technical design (TD)* Do the work. implementation and testing
One such User Story could be Hence, for the Feature "Presentation of MRO objects on the client"As a maintenance worker, I want an there could be multiple successive stories like:* Req/FD: MRO on the client* TD: MRO on the client* Impl.: ACM and Views for MRO on the client* Impl.: Client UI customizing for my work packagesAll of them are rather technical, because I want but all are necessary to see them on implement the mobile deviceFeature."
Every User Story requires a definition-of-done. Those are the acceptance criteria, which can be used to decide whether the Story was done or not. One of these acceptance criteria should always be the peer review, i.e., going over the results with a colleague to check for completeness and optimization on a constructive basis.