A user story describes a need from the end user's perspective, using simple, non-technical language. Use this approach when describing a new feature in DevOps so that the team understands why they are building it, what they are building, and the value it creates.
Establish who has the need, what the need is, and why the need exists.
Write the story as “As a … I want … so that …”, for example, “As a user, I want to submit my application digitally so that it can be processed quickly.”
It is normally the product owner's role to write the user story. If the product owner does not have sufficient insight to do so herself, she is nevertheless responsible for ensuring that someone else completes it.
Break the user story down into acceptance criteria that describe what is required for the story to be accepted as delivered.
Write each criterion so that it can be clearly determined whether it has been met. Feel free to combine functional and quality requirements where relevant.
Use the acceptance criteria as the basis for test tasks and test criteria, so that the developer and tester know exactly what needs to be created and tested.
Use an abbreviated version of the user story as the title, and set the status to whatever the team has agreed should apply when the story is considered “ready”.
Paste the user story into the Description field and the acceptance criteria into the Acceptance Criteria field.
Document the collaboration in the discussion section: ask questions and capture comments as the story develops.
Still et spørsmål eller del hva som hjalp deg.
Publisert 27.1.2026
ProsessPilotene er blant de første selskapene i Norge som er oppført på Microsoft FastTrack Portfolio Partners List - et kvalitetsstempel til leverandører som leverer komplekse Dynamics 365-prosjekter etter dokumentert beste praksis.
Les merHar du et spørsmål eller en erfaring å dele?
Bli den første som bidrar.
