Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • User stories are written in the Design process as part of Backlog grooming by the Product Manager
  • User stories provide the Product Manager and stakeholders insight in the "tasks" the team is working on and related requirements. 
  • User stories are ideally written in parallel to UX & UI design and in close cooperation with those designers.User stories are stored in Jira in the Product Backlog
  • User stories are refined (detailed,  discussed, etc)  in Backlog Grooming sessions and when they reach the top of Product Backlog they might be put into the Sprint backlog during a Sprint Planning meeting


Writing user stories generally starts from the beginning of the Design process, although sometimes it's needed to further clarify overarching requirements (i.e. the related business process or user journey using flow diagram, or the different states of an item using a state diagram). 

Writing and improving user stories is an ongoing process that does not stop until software development has also completed, as even during the Delivery user stories might need to be clarified or split.


Process steps

All steps below should be done are the responsibility of the Product Manager,  but you want to work in parallel, and together with UX&UI Designer(s) . It is the responsibility of PM that all steps are done.  so that i.e. user stories and UX stays aligned and is consistent at the end of the process.

  1. Start high-level requirements analysis. The goal is to learn and get an overview, not to write a requirements document. However you can document high level requirements you encounter in the section "High level requirements" on the Extended User story mapping template (TODO: link to this page when added). Also for point d. Competitor Analysis you should document what you found, in the confluence section "Feature Discussions" on the page related to this theme (TODO: add a section for links to relevant feature discussions to the user story mapping template) 
    1. Top-down requirements analysis (coming from above you in a hierarchy, long-term vision and goals, or laws, etc). Gather, discuss and study:
      1. Relevant company goals or OKR's
      2. Product Vision, Product KPI's, Persona.
      3. Roadmap Theme and Requirements already gathered during Roadmap theme preparation.
      4. Theme Business case
      5. Requirements from relevant stakeholders 
      6. New external API's to be used
    2. Bottom-up requirements analysis (requirements coming from customers, current processes, and systems). Gather, discuss and study:
      1. Relevant existing screens, current system architecture, API's, manual processes/workflows
      2. Relevant data: analytics/revenues/costs / other data points (i.e. for a fraud reduction feature current fraud costs/types /patterns. For a new service: how often was it requested or how many times is a currently a  workaround solution used). 
    3. User Need analysis
      1. Contact Customer Support for input relevant to the theme (support has daily contact with customers. Not talking to them is unacceptable). 
      2. Study relevant User Interview (summaries) and User Test outcomes (from Discovery process) 
      3. Describe the overall Job to be done (JTBD) or Outcomes the User is trying to achieve.
      4. Describe the Persona's
    4. Competitor analysis
      1. Look at least 2 competitors, study their service, put screenshots of their relevant service in the project folder.
  2. Start working on the Design (Specifications and UI). 
    1. Start writing Epics to document the requirements in Jira. Only titles are mandatory. Follow the User Story title naming convention below. Example epics "Order eBook", "Download eBook". Each user role type will have a separate Epic (i.e. buyers, sellers, admins). 
    2. Map out the User Journey for the whole theme (per Actor), using Steps. Use the Extended User Story map for this Some UX designers like to create a Customer Journey Map in parallel which is also based on these steps. 
    3. Per step start writing relevant User stories. Read the paragraphs below about correct user story titles, how to split them up and what makes good user stories. 
    4. Initially, start with just the User Story title, but add them directly to Jira as issue type Design User Story. (If you want to separately track the status of the UI Design part of User Story in Jira you can create subtasks for that, however, you can also use Invision for that). 
    5. Prioritize the User stories together with the UI&UI Designers in Jira in the Design Backlog. Again the User Story map is a great tool to help set priorities. 
    6. Start working on Designs in the Design Backlog priority order. This includes adding user story description including Acceptance criteria (please review the linked page!) and UX&UI Designs. 
    7. In parallel work over overall requirements artifacts as soon as needed for a user story, and only the part that is needed.
      1. the Business Object model to show relationships between entities and Entity Definitions to name and precisely define all entities in the system (i.e. "Order", "NewsItem")
      2. State diagram in case of cross-role workflows or entities for which correct state (transitions) are crucial (i.e. Order, Project) 
      3. Workflow diagrams using UML Activity Diagram for complex human or automated workflows (an entity i.e. a task goes through several stages over several days) 
      4. UX might want to start on the Styleguide and set up a Design system (reusable components) and start on the Information Architecture
    8. If any issues come up during design that somehow prevents moving on what a certain part of the design (i.e. a decision has to be made by a stakeholder, a lawyer has to check something, some API is broken):
      1. Do your best possible assumption and continue the design using that.
      2. Document the issue on an Issue list in Trello. Per issue be very clear about the problem and impact, the proposed next step, the owner of the next step of the priority of this issue in relation to other issues. 
      3. Contact the relevant person about the issue. 
  3. Regularly gather feedback on the Design while it is in progress (again together with UX&UI Designer(s)). The User Story map provides a great tool for this meeting as it gives a process overview. 
    1. Architects about the technical feasibility. Ask the CTO or architect to start working on the technical architecture, tool, and framework selection, etc..
    2. Peers for peer reviews (i.e. other PM's, Head of Product). Recommended: weekly. 
    3. Stakeholders (i.e. CEO, Head of Customer Support)
    4. From end users using User Tests on a (partly) clickable Design in Invision. Recommended: bi-weekly. 
  4. Gather relevant Scrum team for Questions, Feedback, and Estimation in a Backlog grooming session.


  • Title  - I.e. View Authors. 
  • Description containing:
    • Full User story - i.e. As a Blog Administrator I want to see all Authors so I know who has access to Blog Writing functionality
    • Link to clickable Design - i.e.
    • A table with texts that are not visible, i.e. error messages in the primary language of the app (Responsibility of the UXUI Designer)
    • Other information that will help both stakeholders and the team understand the user need.
    • Acceptance criteria (See: Writing Acceptance Criteria). Limit yourself to circa 1-3 acceptance criteria the cover the most important outcomes of the story (not the function, i.e. not which fields should be mandatory, default values, etc)
    • Detailled Detailed requirements. If needed, detailed requirements.
      • Do not include things that can be seen in the UI Design (i.e. which fields/buttons are present). You can include details like which fields are mandatory (if not clear from i.e. data definition table) or what their default values are. An example requirement is: The email address should be validated against ISO-1234.  

User Story Title Naming

Consistency in how we name our user stories makes it easier for everybody to understand the stories. 


A recent trend is defining "Jobs to be Done" when analyzing requirements. This in line with the importance of providing context, situation, motivation and expected outcomes when writing requirements. A JTBD suggestion is to replace Epics or even User stories with "job stories" following the format: When [Situation] I want to [Action] So I can [Expected Outcome] . The (also known as: Given SITUATION When ACTION Then SYSTEMACTION The format itself is not very practical for scrum: It effectively means writing a story for every situation-outcome pair which would lead to a too small unit of work. However clearly defining the situation(s) and the outcome(s) from the user perspective should be part of every user story. I.e. a bad story is "I want to add a Task so the task is stored in the system". This is not an outcome with real user value nor recognize the context. A better one would be " I can easily decide what task to work on next without becoming overwhelmed".