Product owner is a role on an Agile scrum team. The product owner (PO) represents the business or user community and is responsible for working with this group to determine what features will be in the product release. Other roles in scrum include scrum master and development team.

Product Owner Responsibilities, and Tasks

This list includes current tasks undertaken by POs, as well as tasks for which POs share the workload with the Community, SIGs and SMEs

Requirement analysis

Research and gather proposed features and /or user stories and requirements

Review UI mockups with various stakeholders
Work with UX/UI designers on mockups and adherence to FOLIO UI standards
Gather datasets
Document/Define NFRs with team and stakeholders
Define UI permission requirements

Write permissions stories as:
"As a user with permission A, I want to do X."
Permission spreadsheet (see permission)
Document in release notes (see release notes)
Build permission sets in Github and use those for testing

Write up Bugs

Backlog maintenance

Refine development team feature/epic backlog
Refine development team user story backlog
Write/refine UI stories
Ensure MOD(backend modules) stories are outlined and linked to appropriate UI (frontend modules) stories and Feature stories
Review and prioritize bugs for your dev team modules/apps that were submitted by others
Features Prioritization: Review calculated rankings, review/adjust PO rankings to reflect shifting priorities
With scrum master, ensure that sprint management is happening - planning, pointing, reviewing
Work with dev leads to provide high level estimates on features

Platform maintenance

Write accessibility user stories
Ensure personal data is captured
See that your domain/apps contribute to a cohesive FOLIO user experience

Product development

Help other teams with knowledge transfer as related to your team's apps/modules
Coordinate development work across multiple teams for a feature(s)
Help with onboarding new development team members
Coordinate testing across multiple teams for a feature(s)
Respond to questions from developers
Backend User Story Verification (Postman)
Frontend User Story Verification (either snapshot/scratch dev)
Attend scrum ceremonies (scrum, sprint planning, sprint review, sprint retros)

QA and Product Testing

Conduct Usability/User Acceptance Testing (UAT) Testing
Conduct Accessibility Testing
Participate in BugFest

Write QA Tests
Run QA tests
Include permission tests

Performance testing

Write performance test stories

Release management https://folio-org.atlassian.net/wiki/display/REL/Releases+Home

Prepare for Capacity Planning meetings

Update estimates
Identify/Report at-risk features to capacity planning/SIGs

BugFest

Supply BugFest data (if necessary for your testing)
Recruit BugFest participants
Take Bugfest cases when no participant is assigned
Create BugFest test cases
Manage Bugfest test cases

Release notes

Update and maintain release notes

Lead release planning /launch efforts
Attend release meetings
Update Documentation
Manage Hotfix releases

Triage hotfix defects
Validate resolution, test in snapshot
Seek hotfix approval

Stakeholder communication / Customer support

Support knowledge sharing for features you implement (Respond to questions in slack, make presentations to stakeholders etc.)
Address customers and prospects' questions
Lead/attend SIG meetings (include present features/findings)
With dev team, plan, practice, and present FOLIO-wide sprint demos

PO Education

Attend /Participate in PO meetings
Monitor PO Slack channel
Mentor POs
Acquire and enhance PO skills set
Update applicable wiki PO pages

Helpful links

Team vs module responsibility matrix

See Getting Started for Product Owners page for more details on processes and links to resources.

"Thin thread" development

One of the key benefits of scrum development methodology is that it is iterative and incremental. The goal is to release testable software early and often, so that feedback can inform future development. "Thin thread" development supports this goal by putting the emphasis on development of MINIMAL features needed to support an end-to-end workflow, prioritizing those workflows that cross apps.

Writing user stories using "INVEST"

A great mnemonic for structuring user stories is INVEST:

Letter	Meaning	Description
I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another PBI.
N	Negotiable	User stories are not explicit contracts and should leave space for discussion.
V	Valuable	A user story must deliver value to the stakeholders.
E	Estimate-able	You must always be able to estimate the size of a user story.
S	Small	User stories should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
T	Testable	The user story or its related description must provide the necessary information to make test development possible.

https://en.wikipedia.org/wiki/INVEST_(mnemonic)