How to make an agile software user card ?

Agile User Stories are a simple way of capturing user just-in-time requirements throughout a project. They are feature oriented and help to emphasis and cover the why, who, and what on each backlog feature.

So, what makes a good User Story?

The INVEST acronym can help to enlighten this:

I – Independent : Stories are easiest to work with if they are independent
N – Negotiable : they are not contract
V - Valuable : each card might add business value to the customer
E - Estimable: not a precise estimation, the time box can be negotiated.
S - Small : at most a few person-weeks of work
T - Testable : writing the tests early helps to know whether the goal of the User Story is met or not

What should a user story card contain?

There is no fixed template on what a user card should contain, it always depends on the project’s need, more centered, it depends on the need of each product backlog feature, the aim is always to bring everyone to a common understanding of what may be the need and the result.
A common and general template may contain the key points below:

Stakeholder’s description and estimated time .

DBA	Developer	Architect	Estimated time
A	B	C	hours or unite

Story card name or id :
Useful when managing requirements.

Story card goal:
As a User or role I want Business Functionality so that Business Justification

Business scope:
Description of the business added value. (exp: Development of this report will help administrator to send punctual status to investigator when demanded).

Use case scenario :
Not always needed, but helps better understanding.
Exp :
1. Recruiter submits credit card number, date, and authentication information.
2. System validates credit card.
3. System charges credit card full amount.
4. Job posting is made viewable to job seekers.
5. Recruiter is given a unique confirmation number

User Interface with inputs validation.

Security:
who should have access to what.
Exp:
Role ADMIN:Create/ Update /Submit
Role MANAGER: Update /Submit.

Business rules and policies.

Acceptance Criteria:
What makes the story card 100% done.
Exp :
1.Release Specification.
2.Stability Specifications.
3.Process Dependent Specifications.
4.Functionality that the system will perform
5.Interface look and feel
6.Necessary documentation

Comments:
Impediment, impact, estimation… whatever helps historical learning.

The goal is always to better serve the client by keeping the focus on the goal of the product rather than the list of its attributes.