User stories are an industry standard way to express the requirements of different user groups. Wherever possible, write stories that target a single persona. User stories follow this formula: As a __(user persona)__ I want to __(perform some action)__ so that __(outcome or rationale)__.
This is simply the user persona segment that the story describes
Keep actions short and to the point. When exported, into PM software, these will be the "summary" line and so should stand alone to orient a reader to the core of the functionality.
This is where the "why" of the feature or functionality can begin to be expressed. It may be necessary to express practical outcomes, but often these are better listed as Acceptance Criteria
As noted above, job stories substitute this "When" statement for the persona or user-group reference. Userforge also allows the "When" to be specified as an optional enhancement to user stories.
Because opinions and preferences vary between things like "I want to" vs. "I can," each workspace can be configured to use different elements in place of the defaults. This also serves to enable stories in some non-English languages when grammatical structures are sufficiently similar.
Acceptance Criteria (a/c for short) express the minutiae of a feature and can become quite granular. The more complex a story is, the greater its need for some detailed a/c to ensure clarity and common understanding.
Userforge also provides several "Additional Info" sidebar options to enrich stories. These make space for research insights and production notes that add relevant context without cluttering the core story.
User stories can be downloaded via
.csv file for easy external reference or to import into a spreadsheet or project management software other than Jira. We'd love to hear from you re: other integrations you'd like to see.
From the filtered view, when you click the + button, the story creation form will open with the filters applied -- in this case pre-mapped to the location: