What is a Product Owner?
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 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
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 | The user story should be self-contained, in a way that there is no inherent dependency on another PBI. | |
N | User stories are not explicit contracts and should leave space for discussion. | |
V | A user story must deliver value to the stakeholders. | |
E | You must always be able to estimate the size of a user story. | |
S | User stories should not be so big as to become impossible to plan/task/prioritize within a level of accuracy. | |
T | The user story or its related description must provide the necessary information to make test development possible. |
https://en.wikipedia.org/wiki/INVEST_(mnemonic)