Getting Started for Product Owners
The purpose of this page is for Product Owners to know the process for defining requirements and managing those requirements. Dive in!
1) How to stay in touch with your fellow Product Owners
Biweekly meeting: There is a group meeting for Product Owners every two weeks on Wednesdays at 11:00 US ET
Sprint Reviews: Product Owners participate in the Sprint Reviews that are held every 4 weeks (after two two-week sprints have been completed). They occur on the Tuesday following the completion of the second of the two sprints at 11:00-12:30 US ET. (Exceptions are made for holidays.)
Sprint review decks and recordings are on the Google drive here
Private Slack channel: There is also a private #product_owners Slack channel
Contact @Khalilah Gambrell for more information about these meetings/channels. If you are a Product Owner please do sign up for these.
2) Talk with Subject Matter Experts in SIG Meetings
An important part of the PO role is to meet with the SIGs to gather product requirements
The SIG(s) you work with will depend on the epic you are managing
You are welcome to attend any SIG meetings to familiarize yourself with how they operate. If you are new to the project you might want to ping the SIG convener in advance so they can introduce you at the beginning of the call.
You can find a list of the SIGs with links to additional info (including the contact info for the SIG convener) here
Each SIG has a folder on Google Drive. These will contain working documents and may have meeting recordings (though these are not saved consistently).
3) Manage your backlog in Jira
3.1) Jira
List of projects: https://folio-org.atlassian.net/secure/BrowseProjects.jspa?selectedCategory=all
If your team needs a project that is not on the list, please request from Khalilah Gambrell or @Jakub Skoczen
JIRA contains planning backlogs (epics and features) in a project called UXPROD. Development backlogs (e.g. user stories, bugs etc) are maintained in other projects (eg. mod-users and ui-users).
JIRA Hierarchy:
3.2) UXPROD Epics and Features
Higher level work is defined in epics and features in a JIRA project called UXPROD.
3.2.1) UXPROD Epics
Epics are sub-projects in FOLIO. An epic should represent development that may take up to three releases (~about 12 months of development). Definition of Done: Basic functionality is in place and working in production. Advanced functionality should be managed with another epic. It should be a way to describe a workflow/functionality/product at a high level and then user stories and/or features that represent a breakdown of the epic. Agile Alliance definition of an epic (https://www.agilealliance.org/glossary/epic/). The epic kanban board can be found here.
3.2.2) UXPROD Features
POs decompose epics into features based on their conversations with the SIGs and development teams. The idea is to capture larger work increments with as much unstructured description as is available. A well-scoped feature is something that is relatively self-contained so it can be prioritized independently. It should also be something that is “whole” enough to provide value on its own. So, “Manual License CRUD” might be a good feature while “View License Record” or “Validate License Data” would be stories. All stories issues should be linked to features to track progress. Each feature should be linked to one epic.
3.2.3) UXPROD Epic and Feature Workflow/Status and key fields
3.2.4) Splitting UXPROD Features
A UXPROD feature may need to be split (e.g. when it is too large to fit into a release, it is not fully completed in time for the release, there are dependencies and blockers on some aspect of the feature, and/or feature estimates are very large and cannot be completed for the assigned releases). Instructions for splitting features:
Original feature:
1. Keep the original feature in the current release (assuming it was in the current release to begin with)
2. Add the label "split" to the original feature (this will allow us to see how many features in a release were split)
New feature:
1. In the newly spun-off feature, clear out the early implementer rankings if they are populated
2. Make a note at the very top of the feature summary explaining that the feature was split off from another feature (this will be a clear indication to the early implementers and provide a link to the original feature so they can review and revise those rankings as well, if they see fit).
NOTE: Feature splitting is not just an end of a release action. As you get dev estimates from dev team OR you realize that the feature is too large, split so that expectations are reset. Especially if dev estimates are Jumbo.
3.3) Development Backlogs
User stories are the product backlog items that are used by developers to guide their work. Stories are generally written by product owners. The format for user stories is:
User story statement(s) - Including a user story statement is best practice and, if you have them, please include them. They will take the format: As a < type of user >, I want < some goal > so that < some reason >
Scenarios - On FOLIO, acceptance criteria are written as scenarios using the "gherkin syntax" (given, when, then)
Attachments/links - Whenever possible, a UX mockup should be attached or linked to the user story. If there are elements of the mockup that are out of scope for the story (for example, because the technical prerequisites are not in place), then they should be noted as "out of scope for this story"
Some example user stories:
UIU-253 - Loan Actions: Loan Action for Requests
UIREQ-1 - Requests: View Request Details v1
UIU-181 - Assign Proxy v2: Sponsor Sub-Section
Each story should have one and only one linked UXPROD feature.
Story and Bug Workflow/Status and key fields
4) Prepare some mock-ups: UX Design Requests
FOLIO UX designs are stored and accessible from a variety of different tools. This directory on FOLIO's google drive has more up-to-date mockups. Other mockups are found on the wiki. When working with a UX/UI designer it is suggested that the Product Owner:
Create a UX story outlining what needs to be designed and why. Example of UX stories: UX-414, UX-402, UX-399
Include rough mockups in any form from other FOLIO apps or examples from other ILS's to help convey the concepts that need to be designed
Set up a time to discuss the story with the designer
If possible provide real-world data so that it can be included on the mockups that will be created for the story
Depending on the complexity of the project, consider setting up a 15-30 minute meeting twice a week to discuss feedback and iterations
The PO can take the mockups and solicit feedback from the SIGs and Devs and then report back to the designer so that further iterations can be made to the designs
UX Guidelines - Documentation :
FOLIO storybook - documents stripes components
FOLIO design system (needs updates)