Work Items Mental Model Study
What did we learn?
Teams within GitLab have been working for at least 3 years on a way to better organize the different work items within GitLab (epics, issues, projects, etc.) with the goal of making them more extensible and flexible. To get a sense of how people think about the relationships between all of these different objects, we conducted a mental model study so that we can effectively design the product to match the expectations of our users.
Key insights:
- A core group of nouns form the backbone of Work Items, reaching across personas and tools
- We found 3 common workflows in our models that connect Work Items across multiple stages of GitLab
- Task is an inflection point between planning-based tools and code-based tools.
- Story and Roadmap are the most important Work Items that are not a central part of GitLab currently.
For more information: [Include any extra links to reports, Google slides, issues, videos, raw data (if applicable), Dovetail links]
-
📄 Report - Video Walkthrough
-
📃 Speadsheet with raw data, charts, etc. -
📊 Network graph visualization -
🕊 Dovetail with session recordings
Next steps: Hold an Actionable Insights workshop. Identify areas for further research. Incorporate the AI and research issues into the roadmap.
What's this issue all about? (Background and context)
Work items generative/mental model research as suggested in #1702
What are the overarching goals for the research?
Generate user maps of the nouns, verbs and relationships involved in work items, to use in order to validate or adjust our own assumptions about the hierarchy, navigation, nomenclature, and views of work items.
What, if any, relevant prior research already exists?
What timescales do you have in mind for the research?
Who will be leading the research?
Relevant links (opportunity canvas, discussion guide, notes, etc.)
Cards
Steps for the card sort exercise:
- Have each participant group these objects together (may need multiple cards of the same type, also allow "write in" types)
- Bonus: Get each participant to explain the purpose and/or JTBD for each of these objects
- Use one or more relationship cards to connect the objects (will need a lot of the same types of relationship cards)
- Have the participants place one or more relationship modifiers to each relationship card they used.
Objects/Views:
- Theme
- Epic
- Feature
- Story
- Issue
- Task
- Defect
- Maintenance
- Vulnerability
- Incident
- Feature Flag
- Alert
- Merge Request
- Requirement
- Test Case
- Test Session
- Branch
- Commit
- Objective
- Key Result
- Metric
- Group
- Project
- List
- Board
- Roadmap
- Grid
- Calendar
- Report
Verbs:
- Can be a child of
- Can be a parent of
- Can be related to
- Can be blocked by
- Can block
- Can complete/finish
- Belongs to
- Is visible on
Relationship modifiers to compliment each relationship card:
- One
- Many
Other data to try to capture:
-
Planning methodology each participant's team uses (e.g. Scrum, SAFe/Scaled Agile, Kanban, etc) as that seems like it could be a contributing factor. It's also something we can create prebuilt configurations around if that hypothesis is true
😄 - Participant role and utilization of each term to their personal work — we expect that different roles interact with different parts of the planning hierarchy, which this would further solidify. Utilization could be something like "I create", "I update", "I read", "I don't use, but is used at my org" or "Is not used by my org".