Page tree
Skip to end of metadata
Go to start of metadata



Resources

What is a Product Owner?

The FOLIO software development site is available at dev.folio.org

FOLIO uses discuss.folio.org for asynchronous messaging. The Discuss site is a web forum with categories, topics, and posts. Use Discuss for asking questions and recording discussions that require more than a few sentences. 

FOLIO uses wiki.folio.org to store documents with some permanence. FOLIO Special Interest Groups (SIGs), which are dedicated to specific functional areas or interests within FOLIO, have a space on the wiki. 

Join the SIG meeting that is appropriate to the area where you are working: Community Calendars

Sign up for SIG mailing lists so you get all the emails sent to the group(s): https://ole-lists.openlibraryfoundation.org/  Please sign up for the PO distribution list: folio_pos

FOLIO Slack channels for real-time chat are available at folio-project.slack.com. Anyone may request to join the FOLIO Slack channels using an automated web form

FOLIO UX designs can be viewed in the UX prototype.  For some features, especially those in User Management and Resource access, this directory on FOLIO's google drive has more up-to-date mockups.  

The FOLIO Google Drive has working documents for various project groups including most SIGs and the Product Council.  There is a Product Owners sub-folder for our documents.  Contact Anne L. Highsmith to gain access to the FOLIO Google Drive.  Tell her you are a new FOLIO Product Owner.

FOLIO JIRA is the project's issue (bug, story etc.) tracker.  Please sign up and then ask Cate Boerema or Jakub Skoczen for the ability to edit issues. 

Each quarter release has an associated Weekly Status Report.  For example FOLIO Q4 2018 (Aster) Weekly Status Report.  Product owners are asked to add notable changes, issues and risks directly to this report in the "Product Owner Updates" table.  Please do add a comment here if one of your UXPROD features is added or removed from the release.

Please include any mock-ups for your app in the shared Google UX folder, in a sub-folder for your particular app. For access to the UX folder, contact Cate Boerema.

Product Owner Meetings

  • There is a group meeting for Product Owners every two weeks.  
  • Cate Boerema (Lead Product Owner) has individual 1:1 meetings with each PO every two weeks (on opposite weeks of the PO meetings). 
  • The Product Owners meet with the UX Lead once a month to discuss issues that impact both areas. 
  • The 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
  • There is also a private #product_owners Slack channel

(Note: Contact Cate Boerema for more information about these meetings/channels.)

Managing Backlog in JIRA

JIRA (list of projects): https://issues.folio.org/secure/BrowseProjects.jspa?selectedCategory=all

If your team needs a project that is not on the list, please request from Cate Boerema 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

UXPROD Epics and Features

Higher level work is defined in epics and features in a JIRA project called UXPROD.

UXPROD Epics 

Epics are sub-projects in FOLIO.  They are sized so that they require no more than one product owner and can be assigned to a single development team.  Each quarter, the members of the FOLIO Product Council complete a survey in which they stack rank the epics by priority.  This survey results in an epic "score" which helps us determine where to apply new product owners and development teams when they become available.

    • The epic kanban board can be found here
    • The epic list with scores can be found here
      • Some epics don't have scores.  Specifically:
        •  NFRs (non-functional requirements) represent work that must be done and, therefore, we do not collect a community score.  These epics have the label "NFR".  NFR work is accounted for in our project planning as a percentage of development time.
        • "Mandatory" epics are also deemed critical for basic functioning of the product and, as such, are not included in the epic priority survey.  These differ from NFRs in that the work needed to accomplish them is broken out into features which are estimated individually by developers.
        • New epics are epics that have been added since the last epic prioritization survey was conducted.  Unless these are NFRs or Mandatory epics, they will receive a score after the next survey.

UXPROD Features 

POs decompose epics into features based on their conversations with the SIGs.  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.  Stories should be linked to features as "related issues"

    • Features are prioritized by FOLIO early implementers using a survey called the "Gap Analysis".  In the gap analysis, each early implement ranks each feature as needed for:
      1. go-live
      2. can wait for fiscal year rollover
      3. can wait - up to a quarter after go-live
      4. can wait - up to a year
      5. NOT NEEDED
    • The feature ranks collected in the gap analysis are stored in the feature records in JIRA
    • The feature kanban board is here
    • A simple list of features is here
    • Example features:
  • Feature estimates:
    • When features are created, you should ask for them to be estimated (front-end estimate and back-end estimate)
    • This will allow us to stay on top of our project plans and help SMEs make informed tradeoffs regarding what should be prioritized

UXPROD Epic and Feature Workflow/Status 

    • Open - Feature is waiting to be picked up by PO.  
    • Draft - Feature is  being worked on by the PO.  Discussions are happening with the SIGs and sub-groups, mock-ups are being created.  Analysis is underway.
    • Analysis Complete - PO analysis is complete.  Stories are written and mockups have been created.
    • In Progress - Analysis is complete and development is underway.  While it is often the case that we begin development on some aspects of a feature before the PO’s analysis work has been completed, please do not move a feature into Development (In Progress) until after Analysis is Complete.  This is important so we can maintain visibility into what features that have remaining PO work.
    • In Review - Most or all stories in the feature are In Review (being tested)
    • Closed - All stories in the feature have passed test and are closed.  Feature is complete.

Splitting UXPROD Features

UXPROD features sometimes need to be split (e.g. when they are too large to fit into a quarterly release, they are not fully completed in time for the release and/or there are dependencies and blockers on some aspect of the feature).  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).

Make a note in the Weekly Status Report for the relevant quarter (the delivery quarter for the original feature) explaining how and why the feature was split. For example: FOLIO Q4 2018 (Aster) Weekly Status Report

UXPROD Umbrellas (deprecated)

Umbrellas are another type of issue found in UXPROD.  These are deprecated issues that have been superseded by epics or features, but are maintained for the purposes of tracking against the line items from the original (deprecated) v1 roadmap spreadsheet.

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:

  • Purpose - Story context for casual viewers.  What is this story supposed to cover?  If it's just an initial iteration of a larger feature, make that clear here.
  • User story statement(s) - The user story statement is optional and you'll notice that many of our stories don't contain them.  This is because, between the purpose and the scenarios, there is usually more than enough information to go on.  That said, 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 only one linked UXPROD feature.

Story and Bug Workflow/Status

The way "status" is used in JIRA differs depending upon whether you are working with development work items (like stories and bugs) or UXPROD features and epics.  See below for the workflow for UXPROD features and epics.

  • Open - Ready for development
  • Draft - Product owner still drafting.  Not ready for development.
  • In Progress - Development in progress
  • In Review - Ready for manual testing
  • In Code Review - Ready for code review
  • Closed - Complete 

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 convenor 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 convenor) 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).

Observations and Comments Wiki Page

The FOLIO wiki has a page in which manual testers and community members can report observations and issues which they aren't sure are actually defects.  The page is Observations and Comments from Testers/Not Tickets page should be watched by all POs.  If an observation has been added in relation to one of your apps, please review and follow-up as needed.

Additional Information

For who is working on what, please see the Directory of Product Owners by Area of Focus.

Questions about the Product Owner role or processes?  Contact Cate Boerema.

To see the latest screen designs for each area go to FOLIO UX Designs.

To remain abreast of FOLIO news, visit folio.org/news. To remain abreast of FOLIO events worldwide, visit: events.folio.org.



  • No labels