Versions Compared

Old Version 56

changes.mady.by.user Ann-Marie Breaux (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Khalilah Gambrell

Saved on

Key

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

The purpose of this page is for Product Owners to know the process for defining requirements and managing those requirements. Dive in!

Table of Contents

Product Owner Meeting and Communication Channels


...

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 Kelly Drake Khalilah Gambrell for more information about these meetings/channels.  If you are a Product Owner please do sign up for these. 

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 are stored and accessible from a variety of different tools.  There is a UX prototype (no longer maintained).  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

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 Kelly Drake or Jakub Skoczen for the ability to edit issues. 

Managing Backlog in JIRA

...


...

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 Kelly Drake /wiki/spaces/~kgambrell/overview  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:

Drawio
bordertrue
viewerToolbartrue
fitWindowfalse
diagramNameJIRA hierarchy
simpleViewerfalse
width
diagramWidth495
revision1


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

...

.

...

  •  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.

...

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.  Stories All stories issues should be linked to features as "related issues"

...

  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

to track progress. Each feature should be linked to one epic.  

    •  A feature is what an institution reviews to prioritize its needs for go-live and for tracking functionality planned in future releases. It is important that features are
      • Clearly defined and written with the customer in mind. 
      • Describe the problem or need the features will address
      • Describe the benefit(s) of implementing the feature
      • Describe any risk(s) of not implementing the feature 
      • Describe any known dependencies 
      • Use the Template = UXPROD features as a guide 
      • Revise your features as needed so that institutions have an accurate understanding of what will be delivered for a release. A feature set to Closed are included in Release Notes. Example - Kiwi (R3 2021) Release Notes.
    • Use of Labels 
      • Technical debt feature should have the label NFR assigned
      • To allow a SIG to see which features are applicable to the SIG, consider adding the label 


      • SIGLabel
        Usersusermanagement
        Resource Accessresourceaccess
        Resource Managementresourcemanagement
        Electronic resource managementerm
        Metadata Managementmetadatamanagement
        Acquisitionsacquisitions
        Data importdata-import
        Cross Platformcrossplatform


    • The feature kanban board is here
    • A simple list of features is here
    • Example features:
      • Detailed:
    •  
    • issues
    • folio
    • org
    • issues
    • folio
    • org
    • No detail: Lots of features have no detailed description at all.  It's better to record a feature without a description than not recorded it at all!
    • 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

...

    • 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: Development is underway.  It is often the case that we begin development on some aspects of a feature before the PO’s analysis work has been completed.  Use your judgement as to whether the feature should be Draft or In progress in these situations.  If a feature still requires a lot of stories to be written, you should probably leave it in Draft.  If development has begun and you are confident that dev-ready stories won't be a blocker for development, go ahead and move into In Progress.
    • 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

...

    • If development team agrees to work on a feature for a release then assign fields: Development team and Fixed version/s
  • Every release, each team should have a 
    • Technical debt feature > A feature that allocates dev time to unexpected/expected work such as defects, code improvements, etc. [Apply a label NFR ]
  • Question: Managing a feature dependency - Should a team create separate UXPROD feature for another team to complete their portion of work necessary in scope of initially created feature? [Yes -this feature(s) should be agreed upon by teams. Teams should review estimates and discuss expected release dates for features delivery.]

3.2.3)  UXPROD Epic and Feature Workflow/Status and key fields
Anchor
UXPRODWorkflow
UXPRODWorkflow

3.2.4) Splitting UXPROD Features

A UXPROD feature may need to be split (e.g. when they are it is too large to fit into a quarterly release, they are it is not fully completed in time for the release and/or , 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:

...

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

...

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 above 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

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 :


5)  Resources

  • 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
  • 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. 
  • 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 Khalilah 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 /wiki/spaces/~kgambrell/overview or Jakub Skoczen for the ability to edit issues.
  • 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. 

...

  • It 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.


6)  Additional Information

...